ci: create separate workflows for code-quality

[pmarusz]

No description provided.

[Copilot]

Pull Request Overview

This PR restructures GitHub Actions workflows by creating separate, focused workflows for different CI/CD purposes while removing the monolithic previous approach.

• Separates concerns into dedicated workflows for testing, code quality checks, builds, and releases
• Introduces reusable action for test environment preparation
• Streamlines build and release processes with better parameter handling

Reviewed Changes

Copilot reviewed 14 out of 15 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
.github/workflows/run_tests.yml	New workflow for unit and functional test execution with matrix strategy
.github/workflows/pull_requests.yml	Removed old pull request workflow
.github/workflows/pull_request.yml	New simplified pull request workflow for dev builds
.github/workflows/publish_release.yml	New workflow for handling release publishing
.github/workflows/manual_release.yml	Updated manual release workflow with new job structure
.github/workflows/main.yml	New main branch build workflow
.github/workflows/dependency_review.yml	New workflow for dependency security review
.github/workflows/codeql.yml	Simplified CodeQL workflow using reusable workflow
.github/workflows/check_pr_format.yml	New workflow for PR title and commit validation
.github/workflows/check_code_standard.yml	New workflow for code standard checks
.github/workflows/build_upload_whl.yml	Refactored build workflow with improved parameter handling
.github/prepare_test_env/action.yml	New reusable action for test environment setup
.github/dependency_review.yml	Configuration for dependency review settings
.github/dependabot.yml	New Dependabot configuration for dependency updates

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

To resolve this issue, the workflow should explicitly specify the permissions block at the top level, or on relevant jobs, to restrict the default permissions of the GITHUB_TOKEN. For this particular workflow, we should set least-privilege permissions globally, and augment permissions for jobs/steps that require additional scopes.

Since the single job (build_whl) both checks out code (needs contents: read) and publishes pull request comments (needs pull-requests: write for actions/github-script), the safest fix is to put the following at the workflow root (before jobs:):

permissions:
  contents: read
  pull-requests: write

This solution provides only the privileges necessary and not more. The change should be made near the top, after name: and before on: or after on: (GitHub Actions supports both locations).

Summary of required changes:

• Add a permissions block to .github/workflows/build_upload_whl.yml immediately after the workflow name and triggers (recommended after on:).
• The block should grant contents: read and pull-requests: write (since the workflow publishes PR comments).

---

To fix this issue, you should explicitly declare a permissions block in the workflow YAML file to restrict the permissions granted to the GITHUB_TOKEN. Since the workflow steps shown only perform code checkout and code standard checking (no write actions such as deployments, issue or PR creation), the minimal required permission is likely contents: read. Add the following to the root of the workflow (after the name: and before the on: block for maximum clarity and coverage, meaning all jobs inherit these permissions unless otherwise overridden). No additional imports, methods, or formatting changes are required elsewhere; simply add the explicit permissions block.

To fix the problem, set a permissions block at either the workflow root or at the validate_pr_format job level. Since the only job in this workflow is a reusable workflow invocation, the best fix is to add a permissions key at the job level specifying minimal necessary permissions. If the reusable workflow only needs to read PR and branch information and does not use write operations, then contents: read is sufficient; if it requires writing to pull requests (e.g., posting comments/updates) then additionally specify pull-requests: write. The change should be applied within the validate_pr_format job in .github/workflows/check_pr_format.yml, right before or after the uses: line.

The best way to fix this problem is to add a permissions: block to the workflow file .github/workflows/dependency_review.yml, at the root level (i.e., aligned with name: and on:). This will set explicit permissions for the GITHUB_TOKEN used by all jobs in the workflow unless overridden by the reusable workflow. In most cases for dependency review (read-only operations), contents: read is sufficient, but minimally you should set only the permissions required. This prevents the workflow from inheriting broad read-write privileges from the repository or organization.

File/region to change:

• Add the permissions block after the name: and before on:, i.e., between lines 1 and 3.

What is needed:

• Add the following lines:

  permissions:
    contents: read

  This sets the token's permissions for repository contents (the files in the repo) to read-only, which is generally sufficient for dependency review workflows.

---

To fix the problem, add a permissions block at the root of the workflow file .github/workflows/main.yml to specify the required permissions for this workflow. Since most workflows need at least contents: read to check out code, this is a good minimal starting point. If the workflow or build_upload_whl.yml requires additional permissions (such as to publish packages, comment on pull requests, or write to the repository), these should be specified as narrowly as possible, but in the absence of that information we should set contents: read. Insert the block just below the workflow name: declaration and before on:.

---

To resolve the issue, an explicit permissions block should be added to the workflow to specify the GITHUB_TOKEN scope for this job. This can be applied either at the root workflow level (for all jobs) or specifically for the push_release job (since there is only one job). As the job needs to push changes, create commits, tags, and interact with repository contents, it requires at least contents: write permission. If the workflow only pushes tags, releases, and to the branch, contents: write alone is minimally sufficient; further granularity (such as restricting to tags) is not available in GitHub Actions at the moment, so this is as least-privilege as possible for this scenario.
To implement this, add the following block:

permissions:
  contents: write

at the top level of the workflow (immediately after the name: or before/on line 23, for example).

---

To address the issue, add an explicit permissions block to the workflow. This can be set either at the root level (applies to all jobs lacking their own permissions stanza) or at the job level. Best practice is to add at root unless there’s a specific reason to restrict only certain jobs. Since the job likely needs read-only access to contents and possibly minimal rights for actions or pull-requests, the permissions block should specify the minimum required. Based on the job name ("Dev Build") and its configuration (building a wheel via a reusable workflow), there's no evidence it needs writable access, so start with contents: read. If you discover that the workflow pushes changes, uploads artifacts to the repo, or interacts with pull requests, you may add pull-requests: write as needed.

Change required:
In .github/workflows/pull_request.yml, add a permissions: stanza after the name: field and before on:. For most build/test workflows, start with:

permissions:
  contents: read

If you later determine it needs more, adjust accordingly.

---

To fix this issue, we must explicitly add a permissions block to the workflow. Since none of the jobs require write access to the repository or to pull requests or issues, the minimal permission set is contents: read. The best-practice approach is to set permissions: { contents: read } at the top/root level of the workflow (i.e., as a sibling to name, on, and env), so it will apply by default to all jobs unless a job overrides it.

To implement this, insert the following lines directly after the name (line 1), and before on (line 3):

permissions:
  contents: read

No additional methods, imports, or definitions are required.

To fix the issue, we should add a permissions block to the workflow. Since none of the jobs require write access to repository resources, permissions can be set to the minimal recommended value: contents: read. This block should be placed at the root level of the workflow, so that it applies to all jobs by default, unless overridden. No other changes to the workflow logic or steps are required. Only the addition of a root-level permissions block is needed.

To fix the issue, add a permissions: contents: read block at the root level of the workflow YAML file, immediately below the name: field (and above on:). This will apply minimal permissions to all jobs in the workflow, limiting what the generated GITHUB_TOKEN can do. No jobs in this workflow appear to need more than read access to the repo's contents, so this suffices. If any job needs broader permissions in the future, an explicit job-level override can be added.

Steps:

• In .github/workflows/run_tests.yml, after the name: field and before on:, add:

  permissions:
    contents: read

No new imports, definitions, or package installations are necessary.

---

[mfd-intel-bot]

We don't publish DEVs .whl.
To build .whl, run 'pip install git+https://github.com/intel/mfd-code-quality@update-workflow-new-pr'

[Copilot]

Pull Request Overview

Copilot reviewed 14 out of 15 changed files in this pull request and generated 4 comments.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}