chore: add require-linked-issue PR gate - #33
Conversation
… change Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
WalkthroughA new GitHub Actions workflow file ( ChangesRequire Linked Issue CI Gate
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 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 |
codeant-ai
Bot
added
the
size:XS
🏁 CodeAnt Quality Gate ResultsCommit: ✅ Overall Status: PASSEDQuality Gate Details
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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/require-issue.yml:
- Around line 7-8: The `secrets: inherit` directive in the workflow call to the
reusable workflow at
TrySpeed/reusable-workflow/.github/workflows/require-linked-issue.yml is
unnecessarily exposing all repository secrets. Since the require-linked-issue
workflow typically only needs to read PR metadata and does not require secrets,
remove the `secrets: inherit` line entirely. If the reusable workflow does have
specific secret requirements, document them explicitly in its `on.workflow_call`
configuration instead of using the blanket inherit directive.
- Line 7: Replace the `@latest` reference in the reusable workflow `uses`
statement with a specific 40-character commit SHA from the
TrySpeed/reusable-workflow repository to ensure security and stability.
Additionally, replace the `secrets: inherit` configuration with an explicit list
of only the specific secrets that the require-linked-issue workflow requires,
rather than passing all repository and organization secrets to the external
workflow.
🪄 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: CHILL
Plan: Pro
Run ID: 19857525-93db-44e5-973f-77c33fcf7f20
📒 Files selected for processing (1)
.github/workflows/require-issue.yml
| types: [opened, edited, synchronize, reopened] | ||
| jobs: | ||
| issue-gate: | ||
| uses: TrySpeed/reusable-workflow/.github/workflows/require-linked-issue.yml@latest |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's see the actual file content
cat -n .github/workflows/require-issue.ymlRepository: TrySpeed/magento-payment-plugin
Length of output: 357
🏁 Script executed:
# Look for other workflow files and paths-ignore references
find .github/workflows -type f -name "*.yml" -o -name "*.yaml" | head -20Repository: TrySpeed/magento-payment-plugin
Length of output: 146
🏁 Script executed:
# Search for paths-ignore references in workflow files
rg "paths-ignore" .github/workflows/Repository: TrySpeed/magento-payment-plugin
Length of output: 57
🏁 Script executed:
# Check if there are deploy workflows mentioned in the PR
rg "deploy" .github/workflows/ -lRepository: TrySpeed/magento-payment-plugin
Length of output: 57
🌐 Web query:
GitHub Actions best practices pinning reusable workflows @latest security
💡 Result:
Using @latest or any mutable tag (like @main, @v1, or @stable) for reusable workflows creates a significant security risk, as it allows upstream maintainers or attackers who compromise the repository to change the workflow logic without your knowledge [1][2][3]. Best Practices for Pinning Reusable Workflows: 1. Pin to Full-Length Commit SHAs: Use a full-length (40-character) commit SHA for all reusable workflow references [4][3]. This is the only way to ensure the referenced code remains immutable [1][5]. Use a comment to preserve the version tag for readability (e.g., uses: owner/repo/.github/workflows/main.yml@abc123def456... # v1.2.0) [5]. 2. Understand Tooling Limitations: Be aware that some security scanners and CodeQL queries specifically target step-level actions and may miss unpinned reusable workflow calls (job-level uses:) [6]. You must manually audit or use specialized tools (such as pinact or internal custom scripts) to verify that job-level references are also pinned to SHAs [4][1][5]. 3. Implement Organizational Policies: Enable organization-level policies to require SHA pinning [4][1][3]. While some current policies may primarily target step-level actions, they provide a critical baseline. Additionally, use allowlists to restrict which repositories or organizations your workflows can call [4][1]. 4. Avoid Implicit Trust and Secrets: Never use secrets: inherit. This practice passes all repository and organization secrets to the reusable workflow, increasing the blast radius of a compromise [7][8]. Instead, explicitly pass only the specific secrets required by the called workflow [7][8]. 5. Mitigate Transitive Risk: Even if you pin your direct reference, the reusable workflow may call other unpinned actions or workflows [4][9]. Perform reachability analysis or use tools to audit the entire call graph [4]. Consider adopting a cooldown period (e.g., 7–14 days) before updating to a new SHA to ensure the change is not malicious [9]. 6. Validate Inputs: Reusable workflows execute in the caller's security context [4][7]. Always treat all inputs as untrusted data. Use GitHub's typed inputs (e.g., choice, boolean) to restrict values and perform runtime validation for strings to prevent command injection [7]. 7. Verify Commit Ownership: Ensure that the SHA you are pinning belongs to the official, expected repository, not a fork, to prevent dependency confusion attacks [3][8]. Use tools like Zizmor to detect impostor commits [8].
Citations:
- 1: https://mikael.barbero.tech/blog/post/2026-03-24-stop-trusting-mutable-references/
- 2: https://v1.kiranbedi.com/drop/secure-github-actions-pin-versions
- 3: https://docs.github.com/en/actions/reference/security/secure-use
- 4: https://www.systemshardening.com/articles/cicd/github-actions-reusable-workflow-pinning-audit/
- 5: https://safeguard.sh/resources/blog/github-actions-pinning-sha-vs-tag
- 6: actions/unpinned-tag does not flag unpinned reusable workflow calls (job-level uses:) github/codeql#21659
- 7: https://adaptive-enforcement-lab.com/secure/github-actions-security/workflows/reusable/
- 8: https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html
- 9: https://www.wiz.io/blog/github-actions-security-guide
🌐 Web query:
should GitHub Actions reusable workflows be pinned to commit hash security
💡 Result:
Yes, GitHub Actions reusable workflows should be pinned to a full-length commit SHA for security [1][2][3]. Using mutable references—such as tags (e.g., @v1) or branches (e.g., @main)—poses a significant supply chain security risk [1][2][4]. If the repository containing the reusable workflow is compromised, an attacker can modify the code associated with a tag or branch, causing your workflows to execute malicious code without any changes to your own repository [1][2][3]. Pinning to a full-length commit SHA ensures immutability, meaning the code executed will always be the exact content of that specific commit, regardless of future changes to the upstream repository [5][6][4]. Best practices for managing this include: 1. Use SHA pinning: Always reference reusable workflows by their full 40-character commit SHA [2][3][4]. 2. Maintain readability: While the SHA is the technical reference, it is best practice to include the corresponding version tag as a comment in your workflow file (e.g., uses: owner/repo/.github/workflows/reusable.yml@a1b2c3d4... # v1.0.0) [2][4][7]. 3. Automate updates: Manually tracking SHAs can be burdensome. Use tools like Dependabot, Renovate (e.g., with the helpers:pinGitHubActionDigests preset), or specialized tools like pinact to automate the process of updating your pinned SHAs to the latest secure versions [6][8][4][7]. 4. Enforce via policy: If you are using GitHub Enterprise or an organization-level account, enable policies that require actions and reusable workflows to be pinned to full-length commit SHAs [1][4][9]. While enforcement policies primarily target direct action references, you should review all reusable workflow references with equal suspicion and apply the same pinning rigor [1][2]. Note that while SHA pinning protects against "retargeting" attacks where tags are moved, it does not protect against malicious code that is already present in a commit [7]. Therefore, you should only consume reusable workflows from sources you trust [5][2].
Citations:
- 1: https://www.systemshardening.com/articles/cicd/github-actions-reusable-workflow-pinning-audit/
- 2: https://mikael.barbero.tech/blog/post/2026-03-24-stop-trusting-mutable-references/
- 3: https://secure-pipelines.com/ci-cd-security/lab-hardening-github-actions-workflows-permissions-pinning-secrets/
- 4: https://architecture.lullabot.com/adr/20260505-pin-github-actions-to-hash/
- 5: https://docs.github.com/en/actions/reference/security/secure-use
- 6: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
- 7: https://emmer.dev/blog/pin-your-github-actions-to-protect-against-mutability/
- 8: https://github.com/suzuki-shunsuke/pinact
- 9: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
Pin the reusable workflow to a specific commit hash, not @latest.
Using @latest creates a critical security and stability risk. Any changes to the upstream workflow—whether malicious, breaking, or behavioral shifts—will automatically affect this repository without your control. GitHub security best practices and industry standards require pinning to a full-length (40-character) commit SHA.
Additionally, reconsider secrets: inherit on line 8. This passes all repository and organization secrets to the external workflow, increasing the blast radius if the workflow is compromised. Explicitly pass only the specific secrets the reusable workflow requires.
Proposed fix
- uses: TrySpeed/reusable-workflow/.github/workflows/require-linked-issue.yml@latest
- secrets: inherit
+ uses: TrySpeed/reusable-workflow/.github/workflows/require-linked-issue.yml@<COMMIT_SHA>
+ secrets:
+ # Pass only the secrets required by the reusable workflowReplace <COMMIT_SHA> with the desired commit SHA from the TrySpeed/reusable-workflow repository.
🧰 Tools
🪛 zizmor (1.25.2)
[error] 7-7: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[warning] 7-7: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow
(secrets-inherit)
🤖 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/require-issue.yml at line 7, Replace the `@latest`
reference in the reusable workflow `uses` statement with a specific 40-character
commit SHA from the TrySpeed/reusable-workflow repository to ensure security and
stability. Additionally, replace the `secrets: inherit` configuration with an
explicit list of only the specific secrets that the require-linked-issue
workflow requires, rather than passing all repository and organization secrets
to the external workflow.
Source: Linters/SAST tools
| uses: TrySpeed/reusable-workflow/.github/workflows/require-linked-issue.yml@latest | ||
| secrets: inherit |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/require-issue.ymlRepository: TrySpeed/magento-payment-plugin
Length of output: 357
🏁 Script executed:
find . -type f -name "*.yml" -o -name "*.yaml" | grep -E "(workflow|action)" | head -20Repository: TrySpeed/magento-payment-plugin
Length of output: 150
🌐 Web query:
TrySpeed reusable-workflow require-linked-issue secrets requirements
💡 Result:
Based on your request, there is no standardized or official feature named "TrySpeed" related to reusable workflows or issue linking requirements [1][2]. It appears "TrySpeed" may be the name of a specific organization or project (e.g., TrySpeed/magento-payment-plugin) rather than a GitHub Actions feature [1][2]. For implementing issue-linking requirements and managing secrets in standard GitHub Actions reusable workflows, refer to the following authoritative practices: 1. Require Linked Issues: GitHub does not have a native "require-linked-issue" keyword. Developers typically implement this logic using a custom workflow script that checks the Pull Request body for issue references (e.g., "Fixes #123") and ensures the author is authorized [3][4]. These workflows often use the actions/github-script action to parse the PR payload, check issue status, and comment or block the PR if the requirement is not met [3][4]. 2. Secrets in Reusable Workflows: - Explicit Declaration: Reusable workflows must explicitly define required secrets in the on.workflow_call section [5][6]. - Passing Secrets: The caller workflow must pass these secrets using the secrets keyword in the job configuration [5][6]. - Inheritance: Alternatively, you can use secrets: inherit in the caller workflow, which automatically passes all secrets the caller has access to—including organization, repository, and environment secrets—to the called workflow [5][7][8]. - Environment Secrets: If a job in a reusable workflow specifies an environment, it will use that environment's secrets [5]. Note that some users have reported complex behaviors regarding environment-scoped secret resolution in reusable workflows, often requiring secrets: inherit to ensure proper propagation [8]. For specific implementation details regarding your project, you should inspect the.github/workflows directory of the relevant repository to see how they have manually configured these logic checks [3][4][1].
Citations:
- 1: https://github.com/TrySpeed/magento-payment-plugin/blob/055144bf00f7985d01b2078949129527f497eeb9/.github/workflows/codeant-test.yml
- 2: 055144b
- 3: https://github.com/langchain-ai/langchain/blob/master/.github/workflows/require_issue_link.yml
- 4: https://github.com/PrefectHQ/fastmcp/blob/main/.github/workflows/require-issue-link.yml
- 5: https://github.com/github/docs/blob/main/content/actions/how-tos/reuse-automations/reuse-workflows.md
- 6: https://notes.kodekloud.com/docs/GitHub-Actions/Reusable-Workflows-and-Reporting/Step-2-Using-Secrets-in-Reusable-Workflow/page
- 7: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/reusing-workflow-configurations.md
- 8: [BUG] Environment-scoped secrets unreachable from reusable workflow without secrets: inherit, despite called job declaring environment actions/runner#4453
Remove secrets: inherit unless explicitly required by the reusable workflow.
The secrets: inherit directive unconditionally passes all repository secrets to the called workflow. For a "require-linked-issue" check, which typically only needs to read PR metadata, secrets are rarely necessary. Either remove this line or explicitly declare which specific secrets the reusable workflow requires in its on.workflow_call configuration.
🧰 Tools
🪛 zizmor (1.25.2)
[error] 7-7: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[warning] 7-7: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow
(secrets-inherit)
🤖 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/require-issue.yml around lines 7 - 8, The `secrets:
inherit` directive in the workflow call to the reusable workflow at
TrySpeed/reusable-workflow/.github/workflows/require-linked-issue.yml is
unnecessarily exposing all repository secrets. Since the require-linked-issue
workflow typically only needs to read PR metadata and does not require secrets,
remove the `secrets: inherit` line entirely. If the reusable workflow does have
specific secret requirements, document them explicitly in its `on.workflow_call`
configuration instead of using the blanket inherit directive.
Source: Linters/SAST tools
2 participants
User description
Adds the
require-issue.ymlcaller (@latest) so PRs must link aproject-managementissue.Also adds the gate file (and deploy workflows) to each deploy workflow's
paths-ignoreso merging this does NOT trigger a deploy.Refs: TrySpeed/project-management#1105
🤖 Generated with Claude Code
CodeAnt-AI Description
Require a linked issue before a pull request can proceed
What Changed
Impact
✅ Fewer PRs without issue tracking✅ Clearer PR requirements✅ More consistent review process💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Summary by CodeRabbit