Validate Jira base URL before API calls

[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

[Copilot]

Pull request overview

This pull request adds validation for Jira configuration variables before making API calls in the GitHub Actions workflow. The changes improve error handling by checking required environment variables and validating the JIRA_BASE_URL format before attempting to interact with the Jira API.

Changes:

• Added validation to check that required Jira configuration variables (JIRA_BASE_URL, JIRA_EMAIL, JIRA_API_TOKEN, JIRA_KEY) are set
• Added URL scheme validation to ensure JIRA_BASE_URL includes a proper scheme (http:// or https://)
• Added trailing slash normalization for JIRA_BASE_URL to ensure consistent URL formatting

[Copilot]

After normalizing the trailing slash on line 399, the JIRA_BASE_URL is used on line 427 to construct the API endpoint. However, unlike the "Fetch Jira issue JSON" step (line 120), this step doesn't store the normalized URL in an intermediate variable (ISSUE_URL). While the current implementation works, consider adding an ISSUE_URL variable here as well for consistency with the first step and to make the curl command clearer.

[Copilot]

The URL scheme validation only checks if JIRA_BASE_URL starts with "http://" or "https://", but doesn't verify that there's actually a hostname after the scheme. This would allow invalid URLs like "http://" or "https://" to pass validation. Consider adding a more robust check that ensures the URL contains both a scheme and a hostname, for example by checking if the URL contains at least one character after the scheme and "://".

[Copilot]

The URL scheme validation only checks if JIRA_BASE_URL starts with "http://" or "https://", but doesn't verify that there's actually a hostname after the scheme. This would allow invalid URLs like "http://" or "https://" to pass validation. Consider adding a more robust check that ensures the URL contains both a scheme and a hostname, for example by checking if the URL contains at least one character after the scheme and "://".

Suggested change

	host_and_rest="${JIRA_BASE_URL#*://}"
	jira_host="${host_and_rest%%/*}"
	if [ -z "$jira_host" ]; then
	echo "JIRA_BASE_URL must include scheme and host (e.g., https://your-domain.atlassian.net)"
	exit 1
	fi

[Copilot]

The validation logic for Jira configuration is duplicated between this step and the "Comment back on Jira with PR link" step (lines 384-400). Consider extracting this validation into a reusable composite action or a shared shell script to avoid duplication and ensure consistency in validation logic across both steps.

Suggested change

	for v in JIRA_BASE_URL JIRA_EMAIL JIRA_API_TOKEN JIRA_KEY; do
	if [ -z "${!v:-}" ]; then
	echo "Missing required Jira configuration: $v"
	exit 1
	fi
	done
	case "$JIRA_BASE_URL" in
	http://*|https://*) ;;
	*)
	echo "JIRA_BASE_URL must include scheme and host (e.g., https://your-domain.atlassian.net)"
	exit 1
	;;
	esac
	JIRA_BASE_URL="${JIRA_BASE_URL%/}"
	jira_validate_jira_config() {
	for v in JIRA_BASE_URL JIRA_EMAIL JIRA_API_TOKEN JIRA_KEY; do
	if [ -z "${!v:-}" ]; then
	echo "Missing required Jira configuration: $v"
	exit 1
	fi
	done
	case "$JIRA_BASE_URL" in
	http://*|https://*) ;;
	*)
	echo "JIRA_BASE_URL must include scheme and host (e.g., https://your-domain.atlassian.net)"
	exit 1
	;;
	esac
	JIRA_BASE_URL="${JIRA_BASE_URL%/}"
	}
	jira_validate_jira_config