chore: add GitHub Action to create Jira issues on new GitHub issues#511
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 35a6e22990
ℹ️ 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".
| "project": {"key": os.environ["JIRA_PROJECT_KEY"]}, | ||
| "issuetype": {"name": os.environ["JIRA_ISSUE_TYPE"]}, | ||
| "summary": issue_title, | ||
| "description": description, |
There was a problem hiding this comment.
This payload posts to /rest/api/3/issue but sets fields.description to a plain string, which causes issue creation to fail on Jira Cloud instances that require Atlassian Document Format for v3 rich-text fields (the API returns 400 for invalid description shape). Build description as an ADF object (or use v2 if you want plain text) so new GitHub issues consistently create Jira tickets.
Useful? React with 👍 / 👎.
| exit 1 | ||
| fi | ||
| echo "jira_key=$JIRA_KEY" >> "$GITHUB_OUTPUT" | ||
| echo "jira_browse_url=${JIRA_BASE_URL}/browse/${JIRA_KEY}" >> "$GITHUB_OUTPUT" |
There was a problem hiding this comment.
The step explicitly supports JIRA_BASE_URL values that already end with /rest/api/3, but jira_browse_url is built directly from JIRA_BASE_URL; in that valid configuration the posted link becomes .../rest/api/3/browse/<KEY>, which does not resolve to the Jira issue page. Normalize to the site root before composing the browse link.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Pull request overview
This PR adds a GitHub Actions workflow that automatically creates a Jira issue when a new GitHub issue is opened. The workflow validates Jira configuration, builds a payload from the GitHub issue metadata (including title, body, labels, and optional component/priority mappings), creates the Jira issue via REST API, and comments the Jira ticket link back on the GitHub issue.
Changes:
- Added a new GitHub Actions workflow that triggers on GitHub issue creation
- Implemented Jira API integration with configuration validation and error handling
- Added label-to-component and label-to-priority mapping support
- Included support for custom field overrides via label mappings
| echo "jira_browse_url=${JIRA_BASE_URL}/browse/${JIRA_KEY}" >> "$GITHUB_OUTPUT" | ||
|
|
||
| - name: Comment Jira link back on the GitHub issue | ||
| uses: actions/github-script@v7 |
There was a problem hiding this comment.
The workflow uses actions/github-script@v7, but the existing dependabot_automerge.yml workflow uses actions/github-script@v8. For consistency and to use the latest version, consider updating to v8.
| uses: actions/github-script@v7 | |
| uses: actions/github-script@v8 |
|
|
||
| jobs: | ||
| create-jira-ticket: | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
The job does not specify a timeout-minutes value. The existing jira_codex_pr.yml workflow sets timeout-minutes: 60. Consider adding a timeout to prevent the job from running indefinitely if there are issues with the Jira API or network connectivity. A reasonable timeout for this workflow would be 5-10 minutes.
| runs-on: ubuntu-latest | |
| runs-on: ubuntu-latest | |
| timeout-minutes: 10 |
| "$API_BASE/issue") | ||
|
|
||
| if [ "$HTTP_CODE" != "201" ]; then | ||
| echo "Jira issue creation failed. HTTP $HTTP_CODE" |
There was a problem hiding this comment.
When the Jira API call fails, the error message shows the HTTP code and response body, but it doesn't include the request URL or payload that was sent. This makes debugging more difficult. Consider logging the API endpoint URL (without credentials) to help troubleshoot configuration issues.
| echo "Jira issue creation failed. HTTP $HTTP_CODE" | |
| echo "Jira issue creation failed. HTTP $HTTP_CODE" | |
| echo "Request URL: $API_BASE/issue" | |
| echo "Request payload:" | |
| cat jira-payload.json | |
| echo "Response body:" |
| JIRA_BASE_URL="${JIRA_BASE_URL%/}" | ||
| case "$JIRA_BASE_URL" in | ||
| */rest/api/3) API_BASE="$JIRA_BASE_URL" ;; | ||
| *) API_BASE="$JIRA_BASE_URL/rest/api/3" ;; | ||
| esac |
There was a problem hiding this comment.
The JIRA_BASE_URL is not validated to ensure it starts with http:// or https:// before being used. The existing jira_codex_pr.yml workflow includes validation to ensure the URL has a proper scheme. Consider adding the same validation here to prevent configuration errors.
| exit 1 | ||
| fi | ||
|
|
||
| JIRA_KEY="$(jq -r '.key // empty' jira-response.json)" |
There was a problem hiding this comment.
The workflow uses jq to parse the Jira API response (line 143) but doesn't ensure jq is installed. The existing jira_codex_pr.yml workflow includes a step to ensure jq is available. Consider adding the same check here or verifying that jq is pre-installed on ubuntu-latest runners.
| fields = { | ||
| "project": {"key": os.environ["JIRA_PROJECT_KEY"]}, | ||
| "issuetype": {"name": os.environ["JIRA_ISSUE_TYPE"]}, | ||
| "summary": issue_title, | ||
| "description": description, |
There was a problem hiding this comment.
The Jira Cloud REST API v3 expects the 'description' field to be in Atlassian Document Format (ADF), not plain text. The current implementation sends a plain text string, which will likely cause the API request to fail with a 400 error. The description should be formatted as ADF JSON. For example: {"type": "doc", "version": 1, "content": [{"type": "paragraph", "content": [{"type": "text", "text": "your text here"}]}]}.
| fields = { | |
| "project": {"key": os.environ["JIRA_PROJECT_KEY"]}, | |
| "issuetype": {"name": os.environ["JIRA_ISSUE_TYPE"]}, | |
| "summary": issue_title, | |
| "description": description, | |
| adf_description = { | |
| "type": "doc", | |
| "version": 1, | |
| "content": [ | |
| { | |
| "type": "paragraph", | |
| "content": [ | |
| { | |
| "type": "text", | |
| "text": description, | |
| } | |
| ], | |
| } | |
| ], | |
| } | |
| fields = { | |
| "project": {"key": os.environ["JIRA_PROJECT_KEY"]}, | |
| "issuetype": {"name": os.environ["JIRA_ISSUE_TYPE"]}, | |
| "summary": issue_title, | |
| "description": adf_description, |
| exit 1 | ||
| fi | ||
| echo "jira_key=$JIRA_KEY" >> "$GITHUB_OUTPUT" | ||
| echo "jira_browse_url=${JIRA_BASE_URL}/browse/${JIRA_KEY}" >> "$GITHUB_OUTPUT" |
There was a problem hiding this comment.
The jira_browse_url uses JIRA_BASE_URL which may include '/rest/api/3' suffix based on the normalization logic in lines 121-125. This would result in an incorrect browse URL like 'https://domain.atlassian.net/rest/api/3/browse/KEY-123' instead of 'https://domain.atlassian.net/browse/KEY-123'. The browse URL should be constructed from the original base URL before the '/rest/api/3' suffix is added.
Why
This PR addresses the following problem / context:
How
Implementation summary - the following was changed / added / removed:
Notes
Any special considerations, workarounds, or follow-up work to note?