1.0.8.3 code

[bio-boris]

No description provided.

To resolve this issue, explicitly define the permissions: block at the root of the workflow in .github/workflows/manual-build.yml. This ensures that the minimal necessary privileges are granted by the GITHUB_TOKEN during workflow execution. As a starting point, if the workflow’s only requirement is to read from the repository or push to pull requests, set contents: read (and add others only if needed). Since the current workflow delegates to a reusable workflow, and there are no direct steps in this workflow file, contents: read is a safe minimal baseline unless you know more privileges are required.
Steps:

• At the top (after name: is standard), insert a permissions: block specifying minimally required permissions, for instance:

  permissions:
    contents: read
  

• This change should be made in .github/workflows/manual-build.yml before the on: block for clarity and inheritance.

---

To remediate the problem, the workflow file .github/workflows/pr_build.yml should define a permissions block at either the global (workflow) scope or for each individual job. The least privilege setting, unless jobs require specific write access, is typically contents: read. Since this workflow appears to interact with PRs (labels such as "Tag", "Push", and the use of PR events), it is safest to grant contents: read globally. If specific jobs require write permissions for actions like tagging or merging, their associated jobs can be modified later, but the recommended minimum is:

permissions:
  contents: read

This should be added at the workflow root (just after the name: or on: key), so that all jobs default to these permissions unless specifically overridden. No changes to imports or other definitions are needed.

---

To fix the problem, we must add a permissions block to the workflow so that the permissions granted to the GITHUB_TOKEN are restricted according to the principle of least privilege. Ideally, this should be added at the top/root of the workflow, just below the name or before on, so it applies to all jobs unless overridden by specific jobs.

For most build/test workflows that do not require write-level tokens, the minimal default is usually:

permissions:
  contents: read

If the workflow (or any called workflow) needs to create or comment on pull requests, pull-requests: write can also be allowed. But as a minimal fix per the prompt, we will set:

permissions:
  contents: read

This can later be adjusted as needed if more is required, but starting with a minimal read-only approach is best.

Summary of Change:
Edit .github/workflows/pr_build.yml and insert

permissions:
  contents: read

immediately after the name field (after line 2, before line 3 in the snippet).

---

To fix the problem, you should add a permissions block at the root level of the workflow. The minimal and recommended way is to set all permissions to read by default. This means adding the following at the top (after the name: declaration and before on:):

permissions:
  contents: read

If you later find that a particular job requires additional permissions (such as pull-requests: write), you can override it at the relevant job level. However, based on the provided code, there is no explicit sign that more than contents: read is required, so this is a safe least-privilege fix.

How to implement:

• Edit .github/workflows/pr_build.yml.
• Add the following block after the name: label and before the on: block.
• No other changes (such as job-level overrides or added imports) are required, since YAML workflows are declarative.

To fix this issue, add a permissions block at the top of the workflow (global/root-level, immediately after the name: field and before the on: field). This will explicitly limit the permissions of the GITHUB_TOKEN for all jobs in the workflow, unless a job manually overrides them. The best practice is to grant only the minimal privileges required. For build/test-only workflows, contents: read is often sufficient. For push/tag/PR-related workflows, you may need write permissions on specific scopes, but if most jobs only need read-only access, start with contents: read as a baseline. Since the workflow does builds, pushes, and tags, you might need contents: write and possibly packages: write. However, for minimal starting point and best-practice alignment, start with contents: read, and escalate only when required.

Change to be made:

• Insert a block:

  permissions:
    contents: read

  (or extend with permissions actually needed such as packages: write, pull-requests: write, etc if required by actual reusable workflow steps).

Make this change in .github/workflows/pr_build.yml, between name: and on:.

You do not need to modify any code outside this snippet.

---

To fix the problem, an explicit permissions block should be added to the workflow YAML file. The block can be added either at the top-level (to apply to all jobs) or on each job individually. The minimal recommended change is to add the block at the root of the workflow after the name: and before on:, configuring it with least privileges necessary for your workflow. Commonly, setting contents: read suffices for most release processes—if you need to write to pull requests, also add pull-requests: write. In this context, since all jobs use reusable workflows and appear to be only handling release, minimal permissions should suffice. Add the following block (adjust as needed):

permissions:
  contents: read

Insert this after the name: line (line 2) in .github/workflows/release-main.yml.

---

To fix this issue, you should add a permissions key at the top level of the workflow YAML file (.github/workflows/release-main.yml). This key should specify the least-privileged set of permissions needed for the workflow. Unless you know of specific requirements, typically for release and build/push operations, "contents: read" is safe, but if any step needs to write to pull requests or issues, you should explicitly enable only those granular permissions. You can start with:

permissions:
  contents: read

If further permissions are needed for specific jobs, you can override them by adding a permissions block for those jobs. For this initial fix, add the above block at the top-level of the workflow immediately after the name: key (line 2).

---

The best way to fix this issue is to add an explicit permissions: block to the root of the workflow file, restricting permissions to the minimum necessary for the jobs to execute successfully. Since this workflow is triggered on release events and calls other reusable workflows that likely handle release, tag, and build actions, the most restrictive sensible minimal permissions set is likely contents: read (for reading repository contents and metadata) and possibly packages: write or pull-requests: write if publishing images or updating pull requests is required. If you're unsure, start with just contents: read and expand as jobs fail due to lack of permissions. The change should be made near the top of .github/workflows/release-main.yml, immediately following the name: field and before on:.

---