[CLIENT-3467] CI/CD: use orchestrator workflow instead of individual shared workflows#994
Conversation
…frog-release-bundles
…frog-release-bundles
…frog-release-bundles
…frog-release-bundles
…frog-release-bundles
…ecting production...
This reverts commit 0cd96e8.
…frog-release-bundles
…frog-release-bundles
…lease bundle of previous commit
…frog-release-bundles
…frog-release-bundles
…e used both locally and on ci/cd, which is more helpful than cibuildwheel which only works for ci/cd. The downside is we need to manually update our build and repairing dependencies that cibuildwheel comes with
| runs-on: ubuntu-24.04 | ||
| env: | ||
| JF_PROJECT: ${{ inputs.jfrog-project }} | ||
| steps: | ||
| - name: Setup JFrog CLI | ||
| uses: jfrog/setup-jfrog-cli@5b06f730cc5a6f55d78b30753f8583454b08c0aa # v4.8.1 | ||
| env: | ||
| JF_URL: https://artifact.aerospike.io | ||
| with: | ||
| oidc-provider-name: ${{ vars.OIDC_PROVIDER_NAME }} | ||
| oidc-audience: ${{ vars.OIDC_AUDIENCE }} | ||
|
|
||
| - run: jf rbp --signing-key=aerospike --include-repos ${{ inputs.jfrog-repo-name }} ${{ inputs.release-bundle-name }} ${{ inputs.release-bundle-version }} ${{ inputs.new-environment }} |
Check warning
Code scanning / CodeQL
Workflow does not contain permissions Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 3 days ago
In general, the fix is to add an explicit permissions block either at the workflow root or on the specific job so that GITHUB_TOKEN does not default to potentially broad repository/organization permissions. The permissions should be limited to the least privilege necessary for this workflow.
For this specific workflow, the job only sets up the JFrog CLI with OIDC and runs jf rbp .... There is no evidence of creating or modifying issues, pull requests, releases, or repository contents via the GitHub API. The safest change that preserves existing behavior is to add a job-level permissions block that restricts contents to read. If in reality the job does not need GITHUB_TOKEN at all, you could go further and use permissions: {}; however, that may cause future steps added to this reusable workflow to fail unexpectedly. A conservative, compatible fix is therefore:
permissions:
contents: readplaced under the promote-release-bundle-to-dev job, aligned with other job keys like runs-on. No imports or additional methods are needed because this is a GitHub Actions YAML configuration change only.
Concretely, in .github/workflows/promote-release-bundle.yml, update the promote-release-bundle-to-dev job definition (around line 21–24) to insert a permissions block between runs-on: ubuntu-24.04 and env:.
| @@ -20,6 +20,8 @@ | ||
| jobs: | ||
| promote-release-bundle-to-dev: | ||
| runs-on: ubuntu-24.04 | ||
| permissions: | ||
| contents: read | ||
| env: | ||
| JF_PROJECT: ${{ inputs.jfrog-project }} | ||
| steps: |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #994 +/- ##
=======================================
Coverage 83.48% 83.48%
=======================================
Files 99 99
Lines 14402 14402
=======================================
Hits 12024 12024
Misses 2378 2378 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
No description provided.