[ci] Enabled changelog bot from openwisp-utils#611
Conversation
📝 WalkthroughWalkthroughThis PR adds a two-stage GitHub Actions workflow system for automated changelog management. The "Changelog Bot Trigger" workflow activates on approved pull request reviews and validates that the PR title contains a changelog tag ([feature], [fix], or [change]). When matched, it extracts the PR number and uploads it as a Sequence DiagramsequenceDiagram
participant Review as PR Review
participant Trigger as Trigger Workflow
participant Artifact as Metadata Artifact
participant Runner as Runner Workflow
participant Reusable as Reusable Changelog Workflow
Review->>Trigger: approved review + [feature|fix|change] tag
Trigger->>Artifact: upload pr_number
Artifact->>Runner: workflow_run completion
Runner->>Runner: download and validate pr_number
Runner->>Reusable: invoke with PR number + secrets
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Code Review SummaryStatus: No Issues Found | Recommendation: Merge The PR implements a changelog bot workflow that automatically triggers when PRs with specific title prefixes ( What the code does well:
Files Reviewed (2 files)
Reviewed by kimi-k2.5 · 104,066 tokens |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/bot-changelog-runner.yml:
- Around line 41-54: The changelog job ("changelog") uses a workflow_run trigger
and delegates to openwisp/openwisp-utils reusable workflow with pr_number from
needs.fetch-metadata.outputs.pr_number; to mitigate the security concern, ensure
you (1) validate pr_number is numeric and originates from an expected source
before calling the reusable workflow (keep the existing numeric check and add a
source/owner check), (2) pin the reusable workflow ref (replace `@master` with a
specific commit/tag) to avoid code changes in the external repo, and (3) ensure
the reusable workflow itself validates and sanitizes the pr_number input and
does not operate on untrusted data; also confirm secrets (GEMINI_API_KEY,
OPENWISP_BOT_*) remain least-privilege and are only passed to trusted workflows.
- Around line 3-7: The workflow currently triggers on workflow_run (workflows:
["Changelog Bot Trigger"]) and lacks concurrency controls, so add a concurrency
stanza to the top-level workflow that serializes runs: set concurrency.group to
a stable identifier (e.g., use the head_branch value from the triggering run
like "changelog-runner-${{ github.event.workflow_run.head_branch }}" or use
"changelog-runner-${{ github.event.workflow_run.id }}" to serialize globally)
and set concurrency.cancel-in-progress to false to avoid canceling in-progress
updates; place this concurrency block alongside the existing on: workflow_run
configuration to prevent simultaneous changelog updates for the same branch or
globally.
- Line 48: Replace the floating reference to the reusable workflow that
currently uses "`@master`" with a pinned stable tag or commit hash to prevent
accidental breaking changes; specifically update the uses string
"openwisp/openwisp-utils/.github/workflows/reusable-bot-changelog.yml@master" to
the stable release (for example "`@1.2.2`" or the commit "f6305c4") so the
workflow always runs a fixed, reviewed version.
- Line 23: The workflow pins the external action with a mutable tag
("actions/download-artifact@v8"); replace that tag with the action's full commit
SHA to prevent supply-chain tampering (e.g., change "uses:
actions/download-artifact@v8" to "uses:
actions/download-artifact@<FULL_COMMIT_SHA>"). Locate the official
actions/download-artifact repository, find the commit SHA that corresponds to
the v8 release, and update the "uses" entry to that SHA; ensure you commit the
updated workflow so CI uses the immutable reference.
In @.github/workflows/bot-changelog-trigger.yml:
- Around line 3-5: The workflow triggered on pull_request_review lacks
concurrency protection; add a concurrency stanza to the workflow that keys the
group to the PR number (for example using github.event.pull_request.number or an
expression like pull_request-${{ github.event.pull_request.number }}) and set
cancel-in-progress: true so only one instance runs per PR at a time; update the
top-level workflow definition where the on: pull_request_review is declared to
include this concurrency group to prevent race conditions when processing
metadata artifacts.
- Line 7: The workflow currently sets permissions: {} which denies all
permissions and prevents actions/upload-artifact from working; update the
workflow's permissions block to grant the minimal required permission by
replacing permissions: {} with a permissions map that includes contents: read so
the actions/upload-artifact step can upload artifacts successfully (locate the
permissions block and the actions/upload-artifact step in the same workflow to
verify).
- Line 35: Replace the floating tag reference "uses: actions/upload-artifact@v7"
with a pinned commit SHA to mitigate supply-chain risk: locate the workflow step
that uses the actions/upload-artifact action and change the ref from "`@v7`" to
the action's specific commit hash (e.g., "@<commit-sha>") obtained from the
actions/upload-artifact repository, ensuring the new ref points to a stable
commit; update any other occurrences if present and consider documenting the
chosen SHA in the repo or workflow comment for future maintenance.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 51bd7f63-a209-4b9a-9e60-78105fc666f2
📒 Files selected for processing (2)
.github/workflows/bot-changelog-runner.yml.github/workflows/bot-changelog-trigger.yml
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Kilo Code Review
🧰 Additional context used
🪛 zizmor (1.25.2)
.github/workflows/bot-changelog-runner.yml
[error] 3-7: use of fundamentally insecure workflow trigger (dangerous-triggers): workflow_run is almost always used insecurely
(dangerous-triggers)
[error] 23-23: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 48-48: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[warning] 10-10: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
[warning] 17-17: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
[warning] 46-46: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
[info] 13-13: workflow or action definition without a name (anonymous-definition): this job
(anonymous-definition)
[warning] 3-7: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting
(concurrency-limits)
.github/workflows/bot-changelog-trigger.yml
[error] 35-35: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[info] 10-10: workflow or action definition without a name (anonymous-definition): this job
(anonymous-definition)
[warning] 3-5: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting
(concurrency-limits)
🔇 Additional comments (1)
.github/workflows/bot-changelog-runner.yml (1)
30-39: LGTM!
| on: | ||
| workflow_run: | ||
| workflows: ["Changelog Bot Trigger"] | ||
| types: | ||
| - completed |
There was a problem hiding this comment.
Add concurrency control to prevent simultaneous changelog updates.
Without concurrency controls, multiple completions of the trigger workflow could cause simultaneous changelog updates for the same PR, potentially leading to conflicts, duplicate comments, or race conditions in the reusable workflow.
⚡ Proposed fix to add concurrency control
on:
workflow_run:
workflows: ["Changelog Bot Trigger"]
types:
- completed
+concurrency:
+ group: changelog-runner-${{ github.event.workflow_run.head_branch }}
+ cancel-in-progress: false
+
permissions:
actions: readNote: The concurrency group uses head_branch since workflow_run events don't directly expose the PR number. If multiple PRs from the same branch are a concern, consider using github.event.workflow_run.id to serialize all changelog operations globally:
concurrency:
group: changelog-runner
cancel-in-progress: false📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| on: | |
| workflow_run: | |
| workflows: ["Changelog Bot Trigger"] | |
| types: | |
| - completed | |
| on: | |
| workflow_run: | |
| workflows: ["Changelog Bot Trigger"] | |
| types: | |
| - completed | |
| concurrency: | |
| group: changelog-runner-${{ github.event.workflow_run.head_branch }} | |
| cancel-in-progress: false | |
| permissions: | |
| actions: read |
🧰 Tools
🪛 zizmor (1.25.2)
[error] 3-7: use of fundamentally insecure workflow trigger (dangerous-triggers): workflow_run is almost always used insecurely
(dangerous-triggers)
[warning] 3-7: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting
(concurrency-limits)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/bot-changelog-runner.yml around lines 3 - 7, The workflow
currently triggers on workflow_run (workflows: ["Changelog Bot Trigger"]) and
lacks concurrency controls, so add a concurrency stanza to the top-level
workflow that serializes runs: set concurrency.group to a stable identifier
(e.g., use the head_branch value from the triggering run like
"changelog-runner-${{ github.event.workflow_run.head_branch }}" or use
"changelog-runner-${{ github.event.workflow_run.id }}" to serialize globally)
and set concurrency.cancel-in-progress to false to avoid canceling in-progress
updates; place this concurrency block alongside the existing on: workflow_run
configuration to prevent simultaneous changelog updates for the same branch or
globally.
| steps: | ||
| - name: Download PR metadata | ||
| id: download | ||
| uses: actions/download-artifact@v8 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Fetch the commit hash for actions/download-artifact@v8
gh api repos/actions/download-artifact/git/ref/tags/v8 --jq '.object.sha' 2>/dev/null || \
gh api repos/actions/download-artifact/releases/latest --jq '.tag_name as $tag | "Latest tag: \($tag)"'Repository: openwisp/docker-openwisp
Length of output: 109
🏁 Script executed:
cat -n .github/workflows/bot-changelog-runner.yml | sed -n '20,30p'Repository: openwisp/docker-openwisp
Length of output: 474
🏁 Script executed:
# Let's also search for other action usages in this workflow to see the pattern
grep -n "uses:" .github/workflows/bot-changelog-runner.ymlRepository: openwisp/docker-openwisp
Length of output: 203
🌐 Web query:
GitHub Actions best practices action pinning commit hash security 2025
💡 Result:
Best practice for GitHub Actions security in 2025: pin third-party actions to a full (immutable) commit SHA, and (optionally) enforce that via GitHub’s “allowed actions” policy. 1) Use full-length commit SHAs (not tags/branches) GitHub states that “Pin actions to a full-length commit SHA” is the only way to use an action as an immutable release, mitigating the risk of a backdoor being added to the action’s repository by requiring a hard-to-forge SHA-1 collision. [1] Example: uses: actions/checkout@ # vX.Y.Z This pattern (SHA plus a version comment for maintainability) is widely recommended in security guidance and implementation examples. [2][3] 2) Tags are less secure; they can move GitHub notes that if you specify a tag “there is risk… because a tag can be moved or deleted if a bad actor gains access to the repository storing the action.” [1] This is exactly the kind of supply-chain issue that commit-SHA pinning is meant to prevent. [1] 3) Enforce SHA pinning at org/repo level (fail workflows that aren’t pinned) In August 2025, GitHub announced that “allowed actions” policies now support “Enforce SHA pinning”: workflows that attempt to use an action that isn’t pinned to a full commit SHA “will fail.” [4] 4) Verify the SHA is from the original action repository When selecting a SHA, GitHub recommends verifying it is from the action’s repository and not a fork. [1] 5) Maintenance: you still need to update pinned SHAs Pinning improves integrity but doesn’t automatically deliver future security fixes. Teams commonly use automation/workflow tooling to “find unpinned actions” and replace them with the correct SHAs, then test workflows and update documentation. [3] If you want, I can also produce a short checklist (what to pin, what to enforce, and a suggested update workflow) tailored to your repo (public vs private, number of workflows, and whether you can enable org-level policy).
Citations:
- 1: https://docs.github.com/en/actions/reference/security/secure-use
- 2: https://dev.to/jonasbn/pinning-github-actions-and-using-ratchet-3lmc
- 3: Pin all GitHub Actions to immutable SHA commits for supply chain security github/gh-aw#5691
- 4: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
Pin action to commit hash for supply chain security.
The actions/download-artifact@v8 reference uses a tag instead of a commit hash. Tags can be moved or deleted if a bad actor gains access to the repository, creating a supply chain security risk. Pin to the full commit SHA instead:
- uses: actions/download-artifact@v8
+ uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| uses: actions/download-artifact@v8 | |
| uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8 |
🧰 Tools
🪛 zizmor (1.25.2)
[error] 23-23: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/bot-changelog-runner.yml at line 23, The workflow pins the
external action with a mutable tag ("actions/download-artifact@v8"); replace
that tag with the action's full commit SHA to prevent supply-chain tampering
(e.g., change "uses: actions/download-artifact@v8" to "uses:
actions/download-artifact@<FULL_COMMIT_SHA>"). Locate the official
actions/download-artifact repository, find the commit SHA that corresponds to
the v8 release, and update the "uses" entry to that SHA; ensure you commit the
updated workflow so CI uses the immutable reference.
| changelog: | ||
| needs: fetch-metadata | ||
| if: needs.fetch-metadata.outputs.pr_number != '' | ||
| permissions: | ||
| contents: read | ||
| pull-requests: write | ||
| issues: write | ||
| uses: openwisp/openwisp-utils/.github/workflows/reusable-bot-changelog.yml@master | ||
| with: | ||
| pr_number: ${{ needs.fetch-metadata.outputs.pr_number }} | ||
| secrets: | ||
| GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }} | ||
| OPENWISP_BOT_APP_ID: ${{ secrets.OPENWISP_BOT_APP_ID }} | ||
| OPENWISP_BOT_PRIVATE_KEY: ${{ secrets.OPENWISP_BOT_PRIVATE_KEY }} |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider the security implications of workflow_run trigger.
The workflow_run trigger is flagged by security tools as potentially insecure because it runs with elevated privileges in the context of the base repository, even when triggered by forks. However, this workflow mitigates the risk by:
- Validating metadata in lines 35-38 (ensuring PR number is numeric)
- Only processing artifacts from successful workflow runs (line 15)
- Passing validated data to a trusted reusable workflow
The current implementation is reasonably secure, but be aware that any changes to the metadata validation logic or the reusable workflow could introduce vulnerabilities. Ensure the openwisp-utils reusable workflow properly validates and sanitizes inputs.
📚 Additional security considerations
- Ensure the reusable workflow validates the
pr_numberinput and doesn't trust it blindly - Consider adding additional validation of PR ownership/source before making changes
- Monitor the reusable workflow repository for security updates since you're depending on external code
- Document the trust boundary: this workflow trusts artifacts from "Changelog Bot Trigger" which only runs on authorized approvals
🧰 Tools
🪛 zizmor (1.25.2)
[error] 48-48: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[warning] 46-46: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/bot-changelog-runner.yml around lines 41 - 54, The
changelog job ("changelog") uses a workflow_run trigger and delegates to
openwisp/openwisp-utils reusable workflow with pr_number from
needs.fetch-metadata.outputs.pr_number; to mitigate the security concern, ensure
you (1) validate pr_number is numeric and originates from an expected source
before calling the reusable workflow (keep the existing numeric check and add a
source/owner check), (2) pin the reusable workflow ref (replace `@master` with a
specific commit/tag) to avoid code changes in the external repo, and (3) ensure
the reusable workflow itself validates and sanitizes the pr_number input and
does not operate on untrusted data; also confirm secrets (GEMINI_API_KEY,
OPENWISP_BOT_*) remain least-privilege and are only passed to trusted workflows.
| contents: read | ||
| pull-requests: write | ||
| issues: write | ||
| uses: openwisp/openwisp-utils/.github/workflows/reusable-bot-changelog.yml@master |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check available tags and commits for openwisp-utils reusable workflows
echo "=== Recent tags ==="
gh api repos/openwisp/openwisp-utils/tags --jq '.[0:5] | .[] | "\(.name) (\(.commit.sha[0:7]))"'
echo -e "\n=== Latest commit on master ==="
gh api repos/openwisp/openwisp-utils/commits/master --jq '"\(.sha[0:7]) - \(.commit.message | split("\n")[0])"'
echo -e "\n=== Check if reusable workflow exists ==="
gh api repos/openwisp/openwisp-utils/contents/.github/workflows/reusable-bot-changelog.yml --jq '.name'Repository: openwisp/docker-openwisp
Length of output: 329
Pin reusable workflow to a stable version tag or commit hash.
Using @master means this workflow will automatically pull the latest version from the master branch, which could introduce breaking changes without notice. This is a significant security and stability risk.
Based on available versions in openwisp-utils, the latest stable tag is @1.2.2 (commit f6305c4). Pin to this tag or another stable release instead of @master.
📌 Recommended fix
- uses: openwisp/openwisp-utils/.github/workflows/reusable-bot-changelog.yml@master
+ uses: openwisp/openwisp-utils/.github/workflows/reusable-bot-changelog.yml@1.2.2📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| uses: openwisp/openwisp-utils/.github/workflows/reusable-bot-changelog.yml@master | |
| uses: openwisp/openwisp-utils/.github/workflows/reusable-bot-changelog.yml@1.2.2 |
🧰 Tools
🪛 zizmor (1.25.2)
[error] 48-48: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/bot-changelog-runner.yml at line 48, Replace the floating
reference to the reusable workflow that currently uses "`@master`" with a pinned
stable tag or commit hash to prevent accidental breaking changes; specifically
update the uses string
"openwisp/openwisp-utils/.github/workflows/reusable-bot-changelog.yml@master" to
the stable release (for example "`@1.2.2`" or the commit "f6305c4") so the
workflow always runs a fixed, reviewed version.
| on: | ||
| pull_request_review: | ||
| types: [submitted] |
There was a problem hiding this comment.
Add concurrency control to prevent race conditions.
Multiple PR approvals in quick succession could trigger multiple instances of this workflow simultaneously, potentially causing race conditions when the runner workflow processes metadata artifacts. Adding a concurrency group keyed to the PR number ensures only one changelog update runs at a time per PR.
⚡ Proposed fix to add concurrency control
on:
pull_request_review:
types: [submitted]
+concurrency:
+ group: changelog-trigger-${{ github.event.pull_request.number }}
+ cancel-in-progress: false
+
permissions: {}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| on: | |
| pull_request_review: | |
| types: [submitted] | |
| on: | |
| pull_request_review: | |
| types: [submitted] | |
| concurrency: | |
| group: changelog-trigger-${{ github.event.pull_request.number }} | |
| cancel-in-progress: false | |
| permissions: {} |
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 3-5: insufficient job-level concurrency limits (concurrency-limits): workflow is missing concurrency setting
(concurrency-limits)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/bot-changelog-trigger.yml around lines 3 - 5, The workflow
triggered on pull_request_review lacks concurrency protection; add a concurrency
stanza to the workflow that keys the group to the PR number (for example using
github.event.pull_request.number or an expression like pull_request-${{
github.event.pull_request.number }}) and set cancel-in-progress: true so only
one instance runs per PR at a time; update the top-level workflow definition
where the on: pull_request_review is declared to include this concurrency group
to prevent race conditions when processing metadata artifacts.
| pull_request_review: | ||
| types: [submitted] | ||
|
|
||
| permissions: {} |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
GitHub Actions upload-artifact permissions requirements
💡 Result:
For GitHub Actions’ upload-artifact (actions/upload-artifact), the required permissions for the default workflow token are generally minimal: set the workflow’s GITHUB_TOKEN to at least contents: read. - The official guidance for least privilege is to use the workflow permissions model to limit what the GITHUB_TOKEN can do [1]. - An issue in the upload-artifact repository reports testing with workflow base permissions set to permissions: {} in a private repo, and concluded that the only permission needed to upload artifacts was contents: read [2]. Common confusion - “Permission denied” errors you see during the workflow often come from the runner/container filesystem (the action can’t read the local files), not from GitHub token scopes; resolving those requires OS-level access to the files you upload [3]. Practical snippet permissions: contents: read
Citations:
- 1: https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs
- 2: Add details on authentication / permissions used during upload actions/upload-artifact#197
- 3: https://stackoverflow.com/questions/69977574/github-actions-upload-artifact-access-denied-trying-to-upload-a-file-despite
Add minimal permissions to enable artifact upload in this workflow.
Setting permissions: {} denies all permissions to the workflow, which prevents the actions/upload-artifact action at lines 33-39 from working. According to GitHub's official documentation and the upload-artifact repository, only contents: read permission is required for artifact uploads to succeed.
🔒 Fix: Add minimal required permissions
-permissions: {}
+permissions:
+ contents: read📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| permissions: {} | |
| permissions: | |
| contents: read |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/bot-changelog-trigger.yml at line 7, The workflow
currently sets permissions: {} which denies all permissions and prevents
actions/upload-artifact from working; update the workflow's permissions block to
grant the minimal required permission by replacing permissions: {} with a
permissions map that includes contents: read so the actions/upload-artifact step
can upload artifacts successfully (locate the permissions block and the
actions/upload-artifact step in the same workflow to verify).
|
|
||
| - name: Upload PR metadata | ||
| if: steps.check.outputs.has_noteworthy == 'true' | ||
| uses: actions/upload-artifact@v7 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Fetch the commit hash for actions/upload-artifact@v7
gh api repos/actions/upload-artifact/git/ref/tags/v7 --jq '.object.sha' 2>/dev/null || \
gh api repos/actions/upload-artifact/releases/latest --jq '.tag_name as $tag | "Latest tag: \($tag)"'Repository: openwisp/docker-openwisp
Length of output: 109
🏁 Script executed:
cat -n .github/workflows/bot-changelog-trigger.yml | head -50Repository: openwisp/docker-openwisp
Length of output: 1468
🏁 Script executed:
# Search for all 'uses:' statements in the workflow file
rg 'uses:' .github/workflows/bot-changelog-trigger.yml -nRepository: openwisp/docker-openwisp
Length of output: 112
Pin action to commit hash for supply chain security.
The actions/upload-artifact@v7 reference is not pinned to a specific commit hash, which creates a supply chain security risk. If the v7 tag is moved or the action is compromised, the workflow could execute malicious code.
📌 Fix with pinned commit hash
- uses: actions/upload-artifact@v7
+ uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| uses: actions/upload-artifact@v7 | |
| uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a |
🧰 Tools
🪛 zizmor (1.25.2)
[error] 35-35: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/bot-changelog-trigger.yml at line 35, Replace the floating
tag reference "uses: actions/upload-artifact@v7" with a pinned commit SHA to
mitigate supply-chain risk: locate the workflow step that uses the
actions/upload-artifact action and change the ref from "`@v7`" to the action's
specific commit hash (e.g., "@<commit-sha>") obtained from the
actions/upload-artifact repository, ensuring the new ref points to a stable
commit; update any other occurrences if present and consider documenting the
chosen SHA in the repo or workflow comment for future maintenance.
2 participants
Checklist
Description of Changes
Added a changelog bot workflow to automatically update changelogs when PRs are approved.