jira-automation

[jirhiker]

Why

This PR addresses the following problem / context:

• Use bullet points here

How

Implementation summary - the following was changed / added / removed:

• Use bullet points here

Notes

Any special considerations, workarounds, or follow-up work to note?

• Use bullet points here

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 27d711301c

ℹ️ 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".

[chatgpt-codex-connector]

Preserve Basic auth for JIRA_API_TOKEN fallback

Using secrets.JIRA_API_TOKEN as a fallback for JIRA_BEARER_TOKEN is a regression for existing Jira Cloud setups: this workflow previously authenticated with -u "$JIRA_EMAIL:$JIRA_API_TOKEN", but now sends Authorization: Bearer $JIRA_BEARER_TOKEN, so repositories that only have JIRA_API_TOKEN configured will send the API token in the wrong auth scheme and receive 401s when fetching/commenting on issues. Either keep Basic auth when the fallback is JIRA_API_TOKEN or require a true bearer token and remove the fallback.

Useful? React with 👍 / 👎.

[Copilot]

Pull request overview

Updates the jira_codex_pr GitHub Actions workflow to authenticate Jira API requests using an Authorization: Bearer ... header (instead of Basic auth with JIRA_EMAIL:JIRA_API_TOKEN) when fetching the Jira issue and posting a PR link comment back to Jira.

Changes:

• Replaces Jira Basic auth (-u "$JIRA_EMAIL:$JIRA_API_TOKEN") with Bearer auth (-H "Authorization: Bearer $JIRA_BEARER_TOKEN") for Jira REST calls.
• Removes JIRA_EMAIL as a required env var and validates JIRA_BEARER_TOKEN instead.
• Adds a token fallback expression: secrets.JIRA_BEARER_TOKEN || secrets.JIRA_API_TOKEN.

Comments suppressed due to low confidence (2)

.github/workflows/jira_codex_pr.yml:448

• This curl POST uses Bearer auth unconditionally. If the workflow is still configured with Jira email+API token Basic auth, the request will fail. Recommend supporting Basic auth as a fallback (or removing the secrets.JIRA_API_TOKEN fallback so only true Bearer tokens are used here).

          HTTP_CODE=$(curl -sS --retry 3 --retry-delay 2 \
            -H "Authorization: Bearer $JIRA_BEARER_TOKEN" \
            -H "Accept: application/json" \
            -H "Content-Type: application/json" \
            -X POST \
            --data "$payload" \
            -o jira_comment_response.json \
            -w "%{http_code}" \
            "$COMMENT_URL")

.github/workflows/jira_codex_pr.yml:130

• This curl call always uses Authorization: Bearer .... If the repo/environment is still configured with Jira "API token" (meant for Basic auth with email), requests will fail. Suggest supporting both auth schemes (Bearer when JIRA_BEARER_TOKEN is set; otherwise Basic with JIRA_EMAIL + JIRA_API_TOKEN) or updating the secret names so it’s impossible to accidentally send an API token as a Bearer token.

          HTTP_CODE=$(curl -sS --retry 3 --retry-delay 2 \
            -H "Authorization: Bearer $JIRA_BEARER_TOKEN" \
            -H "Accept: application/json" \
            -o jira.json \
            -w "%{http_code}" \
            "$ISSUE_URL")

[Copilot]

JIRA_BEARER_TOKEN falls back to secrets.JIRA_API_TOKEN, but this workflow previously used JIRA_API_TOKEN as an Atlassian API token with Basic auth (email:token). Passing that same value as a Bearer token will likely cause 401s and break existing setups. Consider either (1) keeping the Basic-auth path when JIRA_API_TOKEN/JIRA_EMAIL are provided, and only using Bearer when JIRA_BEARER_TOKEN is set, or (2) removing the fallback and requiring a true Bearer/PAT/OAuth token explicitly.

Suggested change

	JIRA_BEARER_TOKEN: ${{ secrets.JIRA_BEARER_TOKEN || secrets.JIRA_API_TOKEN }}
	JIRA_BEARER_TOKEN: ${{ secrets.JIRA_BEARER_TOKEN }}

[Copilot]

Same concern here: the Jira comment step uses Bearer auth unconditionally while JIRA_BEARER_TOKEN can be populated from secrets.JIRA_API_TOKEN. If JIRA_API_TOKEN is an Atlassian API token (Basic auth), this will break posting the PR link back to Jira. Consider conditional auth handling or requiring a dedicated Bearer token secret.

Suggested change

	JIRA_BEARER_TOKEN: ${{ secrets.JIRA_BEARER_TOKEN || secrets.JIRA_API_TOKEN }}
	JIRA_BEARER_TOKEN: ${{ secrets.JIRA_BEARER_TOKEN }}