🌱 ci: Use centralized reusable workflows from infra repo

[clubanderson]

Summary

• Update common CI workflows to use centralized reusable workflows from kubestellar/infra
• Reduces maintenance overhead and ensures consistency across repositories
• Added pr-verify-title.yml and scorecard.yml workflows

Workflows Updated

• greetings.yml
• feedback.yml
• stale.yml
• pr-verifier.yml
• add-help-wanted.yml
• pr-verify-title.yml (new)
• scorecard.yml (new)

Test plan

• Verify workflows trigger correctly on respective events

🤖 Generated with Claude Code

[kubestellar-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign pdettori for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

In general, the fix is to add an explicit permissions section that restricts the GITHUB_TOKEN to the minimum necessary scopes. This can be done either at the top (root) of the workflow so it applies to all jobs, or within the verify job. Since this workflow only defines one job and calls a reusable workflow, the cleanest fix with minimal functional impact is to add a root-level permissions block granting only read access to repository contents (a safe baseline for most verification jobs). If the reusable verifier needs more, it can request additional scoped permissions within its own definition.

Concretely, in .github/workflows/pr-verifier.yml, insert a permissions: block between the on: section and the jobs: section. A conservative minimal configuration is contents: read, which allows the job to read the repository’s code but not write to it or perform privileged operations. No imports or additional methods are required; this is purely a YAML configuration change within the existing workflow file and does not alter the logical flow of the job.

Generally, the fix is to add an explicit permissions block to the workflow (either at the root level, applying to all jobs, or directly under the analysis job) that limits the GITHUB_TOKEN to the minimal privileges required. For the OpenSSF Scorecard analysis workflow, the recommended baseline is read-only access to repository contents, which is typically sufficient (contents: read) since the action only needs to inspect the repo and not modify it.

The best targeted fix without changing existing functionality is to add a root-level permissions block below the on: section, so it applies to the analysis job (which uses the reusable workflow) unless that reusable workflow overrides it. GitHub’s own Scorecard documentation recommends permissions: contents: read for the caller workflow. Concretely, in .github/workflows/scorecard.yml, add:

permissions:
  contents: read

between the on: block (line 3–9) and the jobs: block (line 11). No additional imports or methods are needed—this is pure GitHub Actions YAML configuration.

In general, you should explicitly declare permissions in the workflow (either at the top level or per job) to restrict the GITHUB_TOKEN to the minimal scopes required. For a stale-issues workflow, typical needs are issues: write (to label/comment/close issues) and, if it also handles PRs, pull-requests: write. If the reusable workflow expects these scopes, granting them at the caller level is appropriate.

The minimal and least-disruptive fix here is to add a permissions block to the stale job, since that’s the job CodeQL flagged. We’ll keep the existing functionality by granting contents: read (safe default for most workflows) and issues: write (and optionally pull-requests: write if PR handling is expected). Because we only see a stale issues workflow name and not full behavior of the reusable workflow, a conservative but still minimal configuration is:

permissions:
  contents: read
  issues: write

This should be added directly under the stale job definition, before uses:. No imports or additional files are required; only .github/workflows/stale.yml is changed.