ci: update workflow

[pmarusz]

No description provided.

[Copilot]

Pull Request Overview

This pull request updates GitHub Actions workflows to use centralized workflow files from the intel/mfd repository instead of local implementations. The changes streamline CI/CD processes by leveraging reusable workflows while maintaining the same functionality for testing, building, and code quality checks.

• Replaced local workflow implementations with calls to centralized workflows in intel/mfd/.github/workflows/
• Added new workflow files for dependency review, PR format validation, and code standard checking
• Updated workflow parameters to match the new centralized workflow interfaces

Reviewed Changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
.github/workflows/run_tests.yml	New workflow calling centralized test runner with matrix strategy for OS and Python versions
.github/workflows/pull_request.yml	New workflow for PR builds using centralized build workflow
.github/workflows/manual_release.yml	Simplified release workflow using centralized release process with updated matrix configuration
.github/workflows/main.yml	New main branch CI workflow using centralized build process
.github/workflows/dependency_review.yml	New workflow for dependency security review
.github/workflows/codeql.yml	Simplified CodeQL workflow using centralized analysis with language matrix
.github/workflows/check_pr_format.yml	New workflow for PR title and commit validation
.github/workflows/check_code_standard.yml	New workflow for code quality standard checks
.github/dependency_review.yml	Configuration file for dependency review settings
.github/dependabot.yml	Configuration for automated dependency updates

---

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

To fix the problem, you should explicitly specify the minimal permissions required at either the workflow or job level. Since the workflow check_pr_format.yml only delegates to a reusable workflow, it is best to set the permissions at the top/root level to ensure coverage for all jobs (unless individual jobs need different permissions, which is not indicated here). For pull request validation tasks, contents: read is generally sufficient unless the reusable workflow requires additional privileges (such as pull-requests: write). Absent further evidence, the minimal safe default is to set contents: read. Add the following lines near the top of the workflow, after the name: and before on: keys:

permissions:
  contents: read

If needed, you can adjust the permissions later based on actual requirements of the workflow.

---

To fix this issue, you should explicitly set the permissions block at the top level of the workflow file (recommended) or at the job level. Since this workflow simply calls a reusable workflow and does not appear to require more than read-only permissions, you should set the permissions to the least privilege required, typically contents: read. If you know that the called workflow requires more permissions (such as for PRs), you may add those specifically. Place the following block at the top level (just after name: and before on:):

permissions:
  contents: read

Edit .github/workflows/dependency_review.yml and insert the above block after the name: line (line 2).

---

[adrianlasota]

it doesn't work when we call pip install -r req-dev.txt for IDE purpose

The best way to fix this problem is to add an explicit permissions block to the workflow. For a reusable workflow like this, placing it at the workflow root (just after the on: block and before jobs) ensures all jobs inherit these default least-privilege permissions unless overridden.
The workflow steps do not need repository write access, but they do interact with pull requests (commenting), which requires pull-requests: write. Most other steps (checkout, reading code, uploading to PyPI) only require contents: read.
Implementation:
Edit .github/workflows/build_upload_whl.yml and, after the name and on: sections (e.g., right before jobs: at line 49), add:

permissions:
  contents: read
  pull-requests: write

This reduces GitHub token permissions to the minimum needed for the workflow: read access to repository contents and write access to pull request comments.

To fix this problem, add a permissions block specifying least-privilege required for the job. This can be done either for the whole workflow (top-level root, right after name: and before on:) or per job (under the job definition). For maintainability and clarity, setting it at the root is recommended unless individual jobs need different permissions.

The minimal starting point is permissions: {} (which gives no access); in practice, you should grant only the privilege needed, such as contents: read, and more only if needed (e.g., issues: write, pull-requests: write). If the workflow only needs read access, use contents: read. If it uploads to releases or creates pull requests, add necessary write scopes.

Where to change:
Insert a permissions: block after name: CI Build (line 1).
If you later discover a job needs more privs, adjust accordingly.

---

To fix the problem, add an explicit permissions: block at the top/root of the workflow (just after the name: or after the on: block but before jobs:), specifying the minimal access rights required. In this case, as all jobs fetch code and possibly post to Coveralls, the minimal required permission is likely contents: read. This will enforce the principle of least privilege for all jobs in the workflow (get_tests_to_run, run_ft_tests, and run_ut_tests). Coveralls may require additional permissions for advanced features, but for badge generation and status posting it only needs contents: read unless otherwise documented.

No further code or import changes are required outside of adding this permissions YAML block.

To fix the problem, we should add an explicit permissions block limiting the GITHUB_TOKEN to the minimum necessary permissions. Since all the jobs listed (including running tests and reporting results to Coveralls) do not need write access to repository contents or metadata, we can set permissions: contents: read at the root of the workflow. This will apply to all jobs. If any individual job needs additional permissions in the future, those can be overridden within that job, but for now, root-level restriction is sufficient.

This change should be made by inserting a permissions: section after the name: (and before env: or jobs:) at the top of the workflow file .github/workflows/run_tests.yml.

To resolve the CodeQL finding, the workflow file .github/workflows/run_tests.yml should explicitly declare a permissions block. The simplest way (and often recommended) is to add it at the root level, just below the workflow name, so all jobs inherit these minimal permissions unless overridden. For typical CI tasks that do not push code or change issues, contents: read is sufficient. If one or more jobs require additional permissions (for example, if the Coveralls action needs to write PR comments or status), individual job permissions can be extended accordingly, but for minimal compliance and security, a root-level block of permissions: contents: read will substantially reduce risk from possible supply chain attacks or privilege escalation. No changes to the existing functionality are needed.

What to change:

• In .github/workflows/run_tests.yml, add a block:

  permissions:
    contents: read
  

  directly below the name: line, before the on: block (after line 1).

Imports, methods, definitions:

• No new imports, methods, or definitions are required for this change.

---

To fix this problem, explicitly add a permissions block to the workflow. The least-privilege approach is to give read-only access to repository contents (contents: read), which is sufficient for checking out code and running static analysis. The permissions block can be added at the root level (before jobs:) so all jobs inherit these permissions unless overridden. Edit the file .github/workflows/check_code_standard.yml: add the following block right after the workflow name: and before the on: trigger section. No additional imports or dependencies are required.

---

To fix the problem, we should add a permissions: key to the workflow. Since the workflow is triggered on pull_request events and calls a reusable workflow for building/uploading a wheel file, we should set the minimum permissions necessary. In almost all cases for a build triggered by a PR, contents: read is sufficient, but if actions in the called workflow require pull-requests: write (e.g., for commenting, updating status), this should be added. For the safest minimal default, set contents: read and add additional scopes as needed. Place the permissions: block at the root of the workflow (above or below on: but before jobs:), so it applies to all jobs unless they override it. No imports or additional definitions are needed.

All the required change is to insert the following at the root of the workflow:

permissions:
  contents: read

You may extend the permission set if write access is required, but with the information shown, contents: read is the minimal starting point.

To fix the problem, you should add a permissions block to the workflow so that the permissions for the GITHUB_TOKEN are explicitly specified and limited to only those required. Since this workflow requires writing to the contents of the repository (for pushes, commits, and tags), you need contents: write rather than the least-privilege of contents: read. All other permissions can be set to none by omitting them.

This block can be placed either at the root of the YAML (to cover all jobs) or at the job level (to impact only this job). Since this workflow contains a single job, adding it at the root is best practice for clarity and future extensibility. You should insert the following immediately after the workflow name: and before on::

permissions:
  contents: write

This ensures the workflow always sets the minimal necessary permissions.

---

[mfd-intel-bot]

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

To fix the issue, you need to add an explicit permissions block to the workflow. This can be done at the root of the workflow (affecting all jobs by default) or at individual job level (overriding the root for those jobs). Since the workflow calls reusable workflows, it is best to limit permissions at the root unless specific jobs need write/update permissions. The minimal starting point for most workflows is permissions: contents: read, unless jobs need to create issues, releases, etc.

Place the following block directly below the name: field at the top for maximum coverage:

permissions:
  contents: read

If you know that your jobs need additional permission types (e.g., for releases), add them as pull-requests: write, etc. Otherwise, start with the minimal read-level access.