Merge feature-business-layer branch into main

[deetz99]

Issue #: bcgov/entity#31285

Description of changes:

• title

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the lear license (Apache 2.0).

To fix the problem, we should add a permissions: block to either the top-level of the workflow (to apply to all jobs) or to the specific job (dissolution-ui-ci). In almost all cases, it's clearest and safest to add a restrictive top-level permission (e.g., contents: read). Then, if any job needs write or broader permissions, individual jobs can override the default. Given that most CI/CD jobs only require contents: read, this is the most secure and future-proof approach. For this code, add after the name: and before the on: section a permissions: block:

permissions:
  contents: read

This will be inherited by all jobs in the workflow, unless they specify their own permissions.

Needed:

• Insert a permissions: block after the first line (name: Dissolution UI CI), before on:.
• No changes to imports, methods, or variables (as this is a YAML workflow).
• If, later, a job requires additional permissions, override in that job.

---

To fix this problem, set a permissions: block at the workflow or job level to restrict the GITHUB_TOKEN to the least required privileges. The minimal permission for most read-only jobs is contents: read. This can be done either at the top level of the workflow (affecting all jobs that don’t set their own permissions), or per job. For clarity and safety, adding permissions: { contents: read } at the top/root is preferred, as none of the jobs shown need to write to the repo (just reading source and uploading/downloading artifacts, which are handled by the respective actions).
You should add the following just after the workflow name and before the on: block:

permissions:
  contents: read

This change only modifies the security context and does not affect workflow functionality.

---

To fix this issue, the workflow must explicitly set the permissions: key at the top level (recommended) or for each job. Since none of the shown jobs require more than basic artifact read/write, they likely only need contents: read, as CodeQL suggested. The best fix is to add the following block immediately after the workflow name: and before on: (after line 1 and before line 3):

permissions:
  contents: read

This configuration ensures that all jobs (unless overridden by a job-specific permissions block) will run with the minimum privileges required for most build jobs. If future jobs require more permissions, these can be granted as needed at the job level.

No other changes (imports, definitions, etc.) are necessary for YAML workflow modifications.

---

To fix this issue, an explicit permissions block should be added to the workflow. This should be placed at the root of the workflow YAML (immediately after name: and before on:) so that it applies to all jobs unless a job-level override is needed. The minimal privilege sufficient for CI tasks is usually contents: read, which provides enough access for the workflow to check out code and access repository files but does not allow write or destructive operations. None of the steps shown require write access to the repository, so contents: read is an appropriate, minimal setting. If future jobs or steps require more permissions (such as for creating issues or comments), those can be scoped appropriately at the job level.

Changes to make:

• Insert a block as follows after the workflow name::

  permissions:
    contents: read

No additional methods, imports, or external definitions are required.

---

To fix the issue, add a permissions block specifying the least privileges needed. According to CodeQL and GitHub security guidelines, the minimal starting point is contents: read, which covers most CI and artifact upload workflows that do not need to write back to the repo (for example, creating releases or pushing code).

The best way to address this is to add a permissions: contents: read block at the workflow root (top-level), right after the name: and before on: so that all jobs inherit read-only permissions. If a specific job later requires more permissions, a job-level override can be used as needed. For the code snippet shown, this affects .github/workflows/person-roles-ci.yaml, and the new block should be inserted after line 1 (immediately after name: Business People UI CI), or before line 3 (on:).

No external imports or dependencies are needed.

---

To fix this issue, you should add a permissions block to either the root of the workflow (making it default for all jobs) or directly to the relevant job(s). Given that this workflow only defines a single job (registry-home-ui-cd), you could add the block at either the job level or workflow level. The most conservative approach, following least-privilege, is to set permissions: {} (no permissions granted) unless you know the job needs access. If minimal read access is required (as with many "CD" deploy jobs), set permissions: read-all. If the deploy process involves, for example, updating deployments or creating releases, you must tailor this block further.

This fix will add permissions: {} at the top-level (just after name:), which means no permissions are granted to the GITHUB_TOKEN by default unless overridden in the called workflow.

---

To fix this issue, the workflow file .github/workflows/registry-home-ci.yaml should be updated to include an explicit permissions: block. This can be set at the root of the workflow (so it applies to all jobs unless a job sets its own permissions), or for the specific job(s) in question. In this case, the best practice is to set it at the top, unless a more restrictive or broader scope is needed for specific jobs. For most CI workflows, contents: read is sufficient, unless the jobs perform GitHub API mutations such as pushing code, opening issues, or manipulating pull requests. Since the shown jobs focus on checking out code, running tests, and uploading artifacts, no write permissions are obviously needed, so contents: read is the minimal safe default.

Steps to implement:

• Add a permissions: block at the root of the YAML file, right after the name: field, setting contents: read.

---

To fix the problem, explicitly add a permissions block to the workflow, limiting the GitHub Actions GITHUB_TOKEN to read-only access to repository contents unless more is needed. Since the highlighted job (and other jobs) only require read access to fetch and test code, and upload artifacts using built-in actions, the minimal required permission is contents: read. This can be added at the workflow root (before jobs: line 14), which will apply to all jobs, unless a particular job needs further permissions (none do here, per the given code). No additional imports or logic are needed in the YAML—this is only a metadata declaration.

---

To fix this problem, add an explicit permissions block at the root level of the workflow (.github/workflows/registry-home-ci.yaml) to enforce least privilege for the GITHUB_TOKEN. Since the workflow only uses actions that interact with code, artifacts, and do not appear to require write access to repository contents, the minimal recommendation is to set permissions: contents: read, ensuring only read access to repository contents. If any job requires higher permissions, job-level permissions blocks can override the root, but based on the shown jobs (installing dependencies, running tests, working with artifacts), contents: read is sufficient. The change should be inserted after the name: and before on: for root-level effect (so all jobs inherit unless overridden).

---

[severinbeauvais]

I see a code conflict and I'd like to see all the checks passing if possible.

[thorwolpert]

Nice, maybe add an issue with followup for the permission settings.

[deetz99]

@cameron-eyds @severinbeauvais @thorwolpert

Sorry folks I goofed this PR, please use #344.

Closing.