chore: add GitHub Action to create Jira issues on new GitHub issues

[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: 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".

[chatgpt-codex-connector]

Send Jira description in ADF for REST API v3

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 👍 / 👎.

[chatgpt-codex-connector]

Derive browse URL from site base, not API base

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 👍 / 👎.

[Copilot]

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

[Copilot]

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.

Suggested change

	uses: actions/github-script@v7
	uses: actions/github-script@v8

[Copilot]

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.

Suggested change

	runs-on: ubuntu-latest
	runs-on: ubuntu-latest
	timeout-minutes: 10

[Copilot]

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.

Suggested change

	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:"

[Copilot]

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.

[Copilot]

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.

[Copilot]

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"}]}]}.

Suggested change

	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,

[Copilot]

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.