CLP-1080: Bump ci-github-actions references from v1 to v2

[mary-georgiou]

CLP-1080

Bumped SonarSource/ci-github-actions/<action>@v1 references to @v2 in the build, PR cleanup, and unified dogfooding workflows.

There is no standalone get-build-number relay job in this repository. build.yml still passes BUILD_NUMBER from the build job to downstream jobs. Keep that output: the analysis job introduced by #588 uses it to download the artifact produced by the build job, and passes the same value to build-maven@v2.

🤖 Generated with Claude Code

[hashicorp-vault-sonar-prod]

CLP-1080

[gitar-bot]

💡 Quality: Manual BUILD_NUMBER handoff left in place despite PR saying none exists

The PR description says no plumbing cleanup was needed. But build.yml still passes the build number by hand: outputs.build-number: steps.build.outputs.BUILD_NUMBER, plus env: BUILD_NUMBER: needs.build.outputs.build-number in build-win, qa and promote. v2 makes this redundant because get-build-number now shares the claimed number across jobs in the same run through Git refs. The equivalent v2 migration in sonar-html PR #830 removes this handoff. Nothing breaks today, but the migration is incomplete and the description is inaccurate. Remove the build-number job output and the BUILD_NUMBER env entries, or correct the description if you want to keep them.

_{Was this helpful? React with 👍 / 👎}

[guillaume-dequenne]

Looks good overall, but I think the comment from Gitar does need to be addressed in this case.

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[datadog-sonarsource]

❌ Errors

Your PR has failed checks. Please review the issues below and take necessary action before merging.

🚦 1 Pipeline job failed

Build | Build

View more details · View in GitHub Actions

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: f0b4596 | Docs | View more details | Give us feedback!}

[gitar-bot]

CI failed: GitHub Actions workflows failed with HTTP 403 during build number generation because bumping ci-github-actions to v2 requires 'contents: write' workflow permissions.

Overview

1 unique configuration failure pattern was found across 2 failed logs. The failure is directly related to the pull request bumping ci-github-actions references from v1 to v2 without sufficient workflow permissions.

Failures

Workflow Permission Denied for v2 Action (confidence: high)

• Type: configuration
• Affected jobs: 111818021995, 111819241900
• Related to change: yes
• Root cause: The workflow fails during the 'Get build number' step with an HTTP 403 error because ci-github-actions v2 requires 'contents: write' in the calling workflow's permissions, which is no longer satisfied by read permissions.
• Suggested fix: Add permissions: contents: write at the job or workflow level for all GitHub Actions workflows that invoke ci-github-actions v2.

Summary

• Change-related failures: 2 jobs failed due to missing contents: write permissions after bumping ci-github-actions to v2.
• Infrastructure/flaky failures: 0 infrastructure or flaky failures.
• Recommended action: Update the workflow permission blocks to include contents: write where v2 actions are executed.

Code Review 👍 Approved with suggestions 1 closed / 2 findings

🔴 High risk · Dogfooding workflow elevates repository contents permission to write for CI actions.

Bumps ci-github-actions references from v1 to v2 across build, PR cleanup, and dogfooding workflows, with dogfooding job permissions corrected to grant contents: write. The manual BUILD_NUMBER handoff through job outputs and environment variables remains in place; consider removing these now-redundant pass-throughs, as v2 uses Git refs to share the build number across jobs in the same run, or clarify in the description if retention is intentional.

💡 Quality: Manual BUILD_NUMBER handoff left in place despite PR saying none exists

📄 .github/workflows/build.yml:24-25 📄 .github/workflows/build.yml:55-56 📄 .github/workflows/build.yml:108-109 📄 .github/workflows/build.yml:160-161

The PR description says no plumbing cleanup was needed. But build.yml still passes the build number by hand: outputs.build-number: steps.build.outputs.BUILD_NUMBER, plus env: BUILD_NUMBER: needs.build.outputs.build-number in build-win, qa and promote. v2 makes this redundant because get-build-number now shares the claimed number across jobs in the same run through Git refs. The equivalent v2 migration in sonar-html PR #830 removes this handoff. Nothing breaks today, but the migration is incomplete and the description is inaccurate. Remove the build-number job output and the BUILD_NUMBER env entries, or correct the description if you want to keep them.

✅ 1 closed

✅ Bug: build-maven@v2 needs contents: write, but dogfooding job only has read

📄 .github/workflows/unified-dogfooding.yml:11-13 📄 .github/workflows/unified-dogfooding.yml:19
In v2, get-build-number (which build-maven calls) no longer updates a repo custom property through a Vault token. It now creates Git refs with the job's own GITHUB_TOKEN. The v2 README says: "This action previously required only contents: read. Claiming now requires contents: write to create Git references. contents: read alone will fail with a 403 on every claim". This is also in the v2 get_build_number.sh: "All ref reads/writes use the ambient GITHUB_TOKEN". The unified-platform-dogfooding job still has contents: read, so after this bump the scheduled dogfooding scan will fail at the build-number step. Fix: set contents: write on this job.

🤖 Prompt for agents

Code Review: Bumps `ci-github-actions` references from v1 to v2 across build, PR cleanup, and dogfooding workflows, with dogfooding job permissions corrected to grant `contents: write`. The manual `BUILD_NUMBER` handoff through job outputs and environment variables remains in place; consider removing these now-redundant pass-throughs, as v2 uses Git refs to share the build number across jobs in the same run, or clarify in the description if retention is intentional.

1. 💡 Quality: Manual BUILD_NUMBER handoff left in place despite PR saying none exists
   Files: .github/workflows/build.yml:24-25, .github/workflows/build.yml:55-56, .github/workflows/build.yml:108-109, .github/workflows/build.yml:160-161

   The PR description says no plumbing cleanup was needed. But build.yml still passes the build number by hand: `outputs.build-number: steps.build.outputs.BUILD_NUMBER`, plus `env: BUILD_NUMBER: needs.build.outputs.build-number` in build-win, qa and promote. v2 makes this redundant because `get-build-number` now shares the claimed number across jobs in the same run through Git refs. The equivalent v2 migration in [sonar-html PR #830](https://github.com/SonarSource/sonar-html/pull/830) removes this handoff. Nothing breaks today, but the migration is incomplete and the description is inaccurate. Remove the `build-number` job output and the `BUILD_NUMBER` env entries, or correct the description if you want to keep them.

Review coverage

🧪 Functional validation 1 of 2 objectives covered

📋 Rules No rules evaluated

🤖 Auto-approval Not enabled · Set up

Implementation Status ◻️ 1 of 2 objectives covered

◻️ CLP-1080 - 1 of 2 objectives covered

This PR covers bumping the ci-github-actions references from v1 to v2.

Other objectives on this issue, possibly covered elsewhere:

• ◻️ Verify and remove unnecessary get-build-number producer/relay plumbing if present

✅ 1 covered here

• ✅ Bump SonarSource/ci-github-actions references from v1 to v2

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}