🌱 Introduce PR conventions check workflow#552
Conversation
Adding a github workflow checking Konveyor-like PR conventions. Adds `:gitmoji: Title` format. Signed-off-by: Marek Aufart <maufart@redhat.com>
📝 WalkthroughWalkthroughA new GitHub Actions workflow file ChangesPR Title Verification Workflow
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 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 |
|
Setting to draft until @istein1 confirms the used emojis are OK for our other project management tool integration. |
Test Coverage ReportTotal: 46.7% Per-package coverage
Full function-level detailsPosted by CI |
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 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/pr-title-check.yml:
- Line 1: The workflow name in the file contains a typo where "Convetions" is
misspelled. Correct the typo by changing "PR Convetions Checks" to "PR
Conventions Checks" in the name field at the top of the workflow file to ensure
proper spelling and clarity in the GitHub Actions UI.
- Around line 16-18: The workflow is using a mutable branch reference (`@main`)
for the konveyor/release-tools/cmd/verify-pr action, which is a supply-chain
security risk, especially when passing GITHUB_TOKEN with broad repository
access. Replace the `@main` reference with a pinned commit SHA (e.g.,
`@abc1234def567890`) for this action. Additionally, apply the same hardening to
other workflows that use similar mutable branch references such as
konveyor/github-actions/require-matching-label@main and
konveyor/github-actions/reconcile-issue@main throughout all workflow files.
- Around line 12-13: The Checkout step is using the deprecated
actions/checkout@v3 which is incompatible with Node.js 20 on current GitHub
Actions runners and poses a security risk by persisting authentication
credentials in git config. Update the uses field from actions/checkout@v3 to
actions/checkout@v4 pinned to a specific commit SHA (like
`@a5ac7e51b41094c153dea493a23456ca4531ec9c`) for supply chain security.
Additionally, add a with section to the Checkout step that sets
persist-credentials to false, since this PR title check workflow only requires
read access to the repository and does not need to push changes or use git
credentials.
- Around line 3-5: The workflow currently uses `pull_request_target` as the
trigger event, which is unnecessarily privileged for this PR title validation
check and creates a security risk on forked PRs. Since this workflow only
validates PR metadata and does not require elevated permissions, replace the
`pull_request_target` trigger with `pull_request` while keeping the same event
types (opened, edited, reopened, synchronize) to reduce the privilege scope.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 5d2888e1-2115-4bd6-a933-13a5228816df
📒 Files selected for processing (1)
.github/workflows/pr-title-check.yml
| @@ -0,0 +1,18 @@ | |||
| name: PR Convetions Checks | |||
There was a problem hiding this comment.
Fix workflow name typo.
PR Convetions Checks should be PR Conventions Checks for clarity in the Actions UI.
🤖 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/pr-title-check.yml at line 1, The workflow name in the
file contains a typo where "Convetions" is misspelled. Correct the typo by
changing "PR Convetions Checks" to "PR Conventions Checks" in the name field at
the top of the workflow file to ensure proper spelling and clarity in the GitHub
Actions UI.
| on: | ||
| pull_request_target: | ||
| types: [opened, edited, reopened, synchronize] |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "pr-title-check.yml" -type fRepository: migtools/crane
Length of output: 97
🏁 Script executed:
cat -n .github/workflows/pr-title-check.ymlRepository: migtools/crane
Length of output: 586
🏁 Script executed:
# Search for any documentation or comments about what verify-pr does
rg "verify-pr\|pr-title-check\|PR Convetions" --type md --type txt -A 3 -B 3Repository: migtools/crane
Length of output: 40
🏁 Script executed:
# Check if there's a README or CONTRIBUTING that mentions the workflow
find . -name "README*" -o -name "CONTRIBUTING*" | head -5Repository: migtools/crane
Length of output: 121
🏁 Script executed:
# Check for any documentation about GitHub workflows or security practices
rg "workflow\|pull_request\|fork\|security" README.md -i -A 2 -B 2Repository: migtools/crane
Length of output: 40
🏁 Script executed:
# Search for other GitHub workflow files to see how other workflows are structured
find .github/workflows -type f -name "*.yml" -o -name "*.yaml" | head -10Repository: migtools/crane
Length of output: 418
🏁 Script executed:
# Check how other workflows use pull_request vs pull_request_target
grep -n "pull_request" .github/workflows/*.yml .github/workflows/*.yaml | head -20Repository: migtools/crane
Length of output: 1206
🏁 Script executed:
# Let's check if the verify-pr action needs repository contents or just metadata
# Check for what the verify-pr action is documented to do
grep -n "checkout\|actions/checkout" .github/workflows/*.yml .github/workflows/*.yamlRepository: migtools/crane
Length of output: 867
🏁 Script executed:
# Let's check if there are any other GitHub workflows that use pull_request_target to understand the pattern
grep -rn "pull_request_target" .github/ --include="*.yml" --include="*.yaml"Repository: migtools/crane
Length of output: 120
Use pull_request (not pull_request_target) for this title-only check.
This workflow only validates PR metadata, so pull_request_target is unnecessarily privileged and widens risk on forked PRs.
Suggested hardening
on:
- pull_request_target:
+ pull_request:
types: [opened, edited, reopened, synchronize]
+
+permissions:
+ contents: read
+ pull-requests: 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.
| on: | |
| pull_request_target: | |
| types: [opened, edited, reopened, synchronize] | |
| on: | |
| pull_request: | |
| types: [opened, edited, reopened, synchronize] | |
| permissions: | |
| contents: read | |
| pull-requests: read |
🧰 Tools
🪛 zizmor (1.25.2)
[error] 3-5: use of fundamentally insecure workflow trigger (dangerous-triggers): pull_request_target is almost always used insecurely
(dangerous-triggers)
🤖 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/pr-title-check.yml around lines 3 - 5, The workflow
currently uses `pull_request_target` as the trigger event, which is
unnecessarily privileged for this PR title validation check and creates a
security risk on forked PRs. Since this workflow only validates PR metadata and
does not require elevated permissions, replace the `pull_request_target` trigger
with `pull_request` while keeping the same event types (opened, edited,
reopened, synchronize) to reduce the privilege scope.
Source: Linters/SAST tools
| - name: Checkout | ||
| uses: actions/checkout@v3 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
actions/checkout v4 v3 deprecation GitHub Actions current version 2025
💡 Result:
As of June 2026, the current major version of actions/checkout is v6 (specifically v6.0.3) [1][2]. Regarding deprecation status: - The version v3 is considered deprecated [3]. GitHub migrated all actions to run on Node.js 20 or higher, and older versions like v3—which relied on older Node.js runtimes—triggered warnings and deprecation notices in CI pipelines starting around 2024 [3][4]. - Users should migrate to a supported major version (v4, v5, or v6) [2][5]. - Versions v4, v5, and v6 remain available, with newer versions offering support for updated Node.js runtimes (e.g., v5 supports Node.js 24) [5]. It is recommended to use the latest version (v6) to ensure compatibility with current GitHub Actions runner environments and security standards [1][2].
Citations:
- 1: https://github.com/actions/checkout/releases/tag/v6.0.3
- 2: https://github.com/actions/checkout/?tab=readme-ov-file
- 3: https://lists.rpm.org/pipermail/rpm-maint/2024-July/028319.html
- 4: https://github.com/orgs/community/discussions/189324
- 5: actions/checkout@08c6903...1af3b93
🌐 Web query:
actions/checkout persist-credentials security best practices
💡 Result:
The persist-credentials input in actions/checkout controls whether the action configures the provided token (defaulting to the GITHUB_TOKEN) or SSH key in the local Git configuration [1][2]. When set to its default value of true, the credentials are stored in the local repository configuration, enabling subsequent workflow steps to execute authenticated Git commands (such as git push or git fetch) without further configuration [1][3]. Security Best Practices - Always set persist-credentials: false for workflows that do not require Git operations (e.g., testing, building, or scanning code) [4][5]. This limits the exposure of credentials to subsequent steps [4][3]. - If you do not require repository write access, follow the principle of least privilege by setting your GITHUB_TOKEN permissions to read-only at the workflow or job level [6][7]. - Be aware that leaving persist-credentials set to true (the default) can lead to credential leakage if the runner's workspace is inadvertently included in uploaded artifacts [8]. Why it matters: - Exposure Risk: If an attacker compromises a later step in your workflow, they could potentially read the persisted credentials from.git/config and use them to perform unauthorized Git operations, such as pushing malicious code to your repository [6][3][5]. - Artifact Leakage: A known risk, sometimes called "Artipacked," occurs when the entire workspace (which includes the.git/config file containing the credentials) is uploaded as an artifact, exposing the token to anyone with access to that artifact [8]. Configuration Example: To disable credential persistence, update your checkout step as follows [3][8]: - uses: actions/checkout@v4 with: persist-credentials: false Note: This configuration is intended for read-only workflows. If your workflow specifically needs to perform authenticated Git operations, you must keep it enabled (or use an alternative secure method for authentication) [4][1][5].
Citations:
- 1: https://github.com/actions/checkout
- 2: https://github.com/actions/checkout/blob/34e114876b0b11c390a56381ad16ebd13914f8d5/action.yml
- 3: https://actsense.dev/vulnerabilities/unsafe_checkout/
- 4: https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html
- 5: Add persist-credentials: false to GitHub Actions checkout steps aquasecurity/trivy#10305
- 6: Remove
persist-credentialsor change the default tofalseactions/checkout#485 - 7: [security] Escalate concerning default
persist-credentials=trueplease actions/checkout#2312 - 8: https://sisaku-security.github.io/lint/docs/rules/artipacked/
🌐 Web query:
GitHub Actions pinning to commit SHA vs version tag security
💡 Result:
Pinning GitHub Actions to a full-length commit SHA is the only method to ensure an immutable, secure reference, effectively mitigating supply chain attacks where a malicious actor gains control of an action's repository and updates a tag to point to compromised code [1][2][3]. Key security and operational considerations include: Security Benefits of SHA Pinning * Immutability: A tag (e.g., v4) is a mutable pointer that can be updated at any time by the repository maintainer [2][4][5]. If an account is compromised, attackers can update existing tags to inject malicious code [6][7]. A commit SHA is a unique, immutable identifier for a specific version of code; once pinned, your workflow will always execute that exact version, regardless of upstream changes [1][4][5]. * Policy Enforcement: Organizations can mandate SHA pinning through GitHub policy settings at the repository or organization level [1][8][9]. When enabled, any workflow referencing an action by a non-SHA tag will fail, forcing compliance across the dependency tree, including internal sub-actions [8][9][3]. Operational Best Practices * Human-Readable References: Because commit SHAs are not human-readable, the established best practice is to pin to the SHA while including the version tag as a comment in the workflow file (e.g., uses: actions/checkout@b4ffde6... # v4.1.1) [7][10]. * Automated Updates: Manually maintaining SHAs is inefficient. Tools like Dependabot and Renovate are recommended to automatically create pull requests that update pinned SHAs when the upstream version tag moves [6][7][5]. This maintains security without sacrificing the ability to receive updates [7]. * Addressing Composite Actions: Security risks also extend to internal references. If you maintain a composite action, you must pin any sub-actions you reference to full commit SHAs; otherwise, you may block downstream users who enforce strict SHA-pinning policies [9][10]. * Limited Scope: SHA pinning does not protect against an attacker who pushes a new, malicious, but otherwise valid, version of an action that you then manually or automatically update to [2][6]. It is a defense-in-depth measure that must be combined with regular dependency auditing, the use of trusted sources, and reviewing automated dependency update PRs [2][7][3].
Citations:
- 1: https://docs.github.com/en/actions/reference/security/secure-use
- 2: https://safeguard.sh/resources/blog/github-actions-pinning-sha-vs-tag
- 3: https://blogs.eclipse.org/post/mika%C3%ABl-barbero/stop-trusting-mutable-references-how-eclipse-foundation-projects-should-harden
- 4: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
- 5: https://www.cncf.io/blog/2026/05/04/securing-github-actions-ci-dependencies-recipe-card/
- 6: https://emmer.dev/blog/pin-your-github-actions-to-protect-against-mutability/
- 7: https://architecture.lullabot.com/adr/20260505-pin-github-actions-to-hash/
- 8: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 9: https://www.romainlespinasse.dev/posts/github-actions-commit-sha-pinning/
- 10: https://adaptive-enforcement-lab.com/secure/github-actions-security/action-pinning/sha-pinning/
Upgrade to v6 and harden the checkout step.
actions/checkout@v3 is deprecated as of 2024 and incompatible with current GitHub Actions runners using Node.js 20. Additionally, default credential persistence leaves the authentication token in local git config, exposing it to compromise if the workflow workspace is inadvertently included in artifacts or if a later step is exploited.
Since this PR title check workflow only reads repository content, disable credential persistence and pin to a commit SHA for immutability and supply chain security:
Suggested hardening
- name: Checkout
- uses: actions/checkout@v3
+ uses: actions/checkout@<full-length-commit-sha> # v6
+ with:
+ persist-credentials: false🧰 Tools
🪛 actionlint (1.7.12)
[error] 13-13: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🪛 zizmor (1.25.2)
[warning] 12-13: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 13-13: 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/pr-title-check.yml around lines 12 - 13, The Checkout step
is using the deprecated actions/checkout@v3 which is incompatible with Node.js
20 on current GitHub Actions runners and poses a security risk by persisting
authentication credentials in git config. Update the uses field from
actions/checkout@v3 to actions/checkout@v4 pinned to a specific commit SHA (like
`@a5ac7e51b41094c153dea493a23456ca4531ec9c`) for supply chain security.
Additionally, add a with section to the Checkout step that sets
persist-credentials to false, since this PR title check workflow only requires
read access to the repository and does not need to push changes or use git
credentials.
Source: Linters/SAST tools
| uses: konveyor/release-tools/cmd/verify-pr@main | ||
| with: | ||
| github_token: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check if the file exists and read the specific lines
cat -n .github/workflows/pr-title-check.yml | sed -n '14,20p'Repository: migtools/crane
Length of output: 252
🏁 Script executed:
# Search for other instances of `@main` in GitHub Actions workflows
find .github/workflows -name "*.yml" -o -name "*.yaml" | xargs rg "`@main`" || echo "No `@main` references found"Repository: migtools/crane
Length of output: 675
🏁 Script executed:
# Check if there are other uses of konveyor/release-tools in the codebase
rg "konveyor/release-tools" .github/workflows/Repository: migtools/crane
Length of output: 149
Pin verify-pr to a commit SHA instead of @main.
Using a mutable branch ref for a third-party action is a supply-chain risk. This is especially critical when passing GITHUB_TOKEN, which grants the action broad access to the repository.
Suggested hardening
- uses: konveyor/release-tools/cmd/verify-pr@main
+ uses: konveyor/release-tools/cmd/verify-pr@<full-length-commit-sha>Note: Similar patterns exist in other workflows (e.g., konveyor/github-actions/require-matching-label@main, konveyor/github-actions/reconcile-issue@main). Consider applying the same hardening across all workflow files.
🧰 Tools
🪛 zizmor (1.25.2)
[error] 16-16: 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/pr-title-check.yml around lines 16 - 18, The workflow is
using a mutable branch reference (`@main`) for the
konveyor/release-tools/cmd/verify-pr action, which is a supply-chain security
risk, especially when passing GITHUB_TOKEN with broad repository access. Replace
the `@main` reference with a pinned commit SHA (e.g., `@abc1234def567890`) for this
action. Additionally, apply the same hardening to other workflows that use
similar mutable branch references such as
konveyor/github-actions/require-matching-label@main and
konveyor/github-actions/reconcile-issue@main throughout all workflow files.
Source: Linters/SAST tools
As discussed on team call, adding a github workflow checking Konveyor-like PR conventions, primary
:gitmoji: Titleformat.Examples: https://github.com/konveyor/release-tools/blob/main/pkg/pr/prefix.go#L12-L38
Summary by CodeRabbit