ci: add new reusable workflow

[pmarusz]

No description provided.

[Copilot]

Pull Request Overview

This PR migrates the GitHub Actions workflows from local implementations to reusable workflows hosted in the intel/mfd repository. The changes replace inline workflow definitions with calls to centralized workflows, simplifying maintenance and ensuring consistency across projects.

Key changes:

• Replace local workflow implementations with reusable workflow calls
• Consolidate workflow triggers and job configurations
• Add new workflows for dependency review, PR validation, and code standards

Reviewed Changes

Copilot reviewed 11 out of 11 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 reusable test execution workflow
.github/workflows/pull_requests.yml	Removed - replaced by pull_request.yml
.github/workflows/pull_request.yml	New workflow calling reusable PR build workflow
.github/workflows/manual_release.yml	Updated to use reusable release workflow with simplified matrix
.github/workflows/main.yml	New workflow calling reusable main branch build workflow
.github/workflows/dependency_review.yml	New workflow for dependency security checks
.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 validation
.github/workflows/build_upload_whl.yml	Removed - functionality moved to reusable workflows
.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 this problem, set the least-privilege permissions for GITHUB_TOKEN by adding a permissions: block. Since the job is performing check-standard tasks on pull_request events, the safest default is contents: read unless more privileges are required. Add the block at the job level (run_check_standard), directly above the strategy: section at line 9. This ensures that the job only uses GITHUB_TOKEN for read access to repo contents and cannot write to the repository, issues, or PRs. No imports or package changes are needed; simply modify the YAML structure.

---

To fix the problem, add an explicit permissions block to the job or workflow file, setting only the least privileges required. For most build/test jobs (particularly if they only need to checkout code and do not push, open pull requests, or write to repositories), the minimal contents: read permission is sufficient. The best way to fix this is to add permissions: contents: read at the job definition (indentation matched to the job level, i.e., right below the job name and just above strategy). This change should be made directly in .github/workflows/main.yml for the build_whl job. No other lines or files should be touched.

---

To fix the issue, you should explicitly set a permissions block at the workflow or job level to limit the privileges of the GITHUB_TOKEN to only what is strictly necessary. The best practice is to set this at the root of the workflow (top-level), but you can also set it inside the job definition. Given this workflow likely only needs to read contents and possibly write to pull requests (to comment/status, etc.), the minimal fix is:

At the top-level (before jobs:), add:

permissions:
  contents: read
  pull-requests: write

Alternatively, if your workflow does not need to write to pull requests, you can further restrict. The lines should be added right after the workflow name: and on: keys but before jobs:.

[mfd-intel-bot]

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

To fix the problem, a permissions block should be explicitly added to the workflow or the relevant job to limit the GitHub token’s permissions. Since the job appears to only validate PR format (not make changes), it likely only needs read access. The most secure approach is to set the permissions at the workflow root, applying to all jobs by default. If the job or called workflow requires specific permissions, these can be set later, but the least privilege is contents: read. The fix only involves adding a permissions block after the workflow’s name line.

---

To fix the problem, add a permissions block, either at the workflow root or under the specific job (dependency_review). Since this workflow’s job simply uses another workflow and likely needs only minimal permissions associated with dependency review (primarily contents: read), it’s best to add the most restrictive set possible. Modify .github/workflows/dependency_review.yml to include a permissions block at the root level, granting only the minimal necessary permissions (usually contents: read). This can be inserted after the name: field and before the on: field to apply to the whole workflow (recommended), unless deeper inspection of the reusable workflow indicates the need for additional privileges.