[TT-17507] Move jira-linter to github-actions

[buraksezer]

PR for https://tyktech.atlassian.net/browse/TT-17507

Changes

• Moved TykTechnologies/jira-linter composite action source code into jira-linter directory
• Replaced unused cyrus-za/jira-lint reusable workflow with the in-house implementation
• Added Go test job to CI
• Updated dependabot config for Go module updates

Caller Migration

After merge, 20 repos need to update their jira-pr-validator.yaml:

TykTechnologies/jira-linter@main → TykTechnologies/github-actions/jira-linter@main

List of repos:

• ara
• graphql-translator
• portal
• portal-admin
• portal-api-tests
• storage
• tyk
• tyk-analytics
• tyk-analytics-ui
• tyk-ara-ui
• tyk-charts
• tyk-gql
• tyk-identity-broker
• tyk-operator-internal
• tyk-pump
• tyk-pump-proof
• tyk-sink
• tyk-sink-proof
• tyk-sync-internal
• tyk-ui

[probelabs]

This pull request migrates the jira-linter functionality from a separate repository (TykTechnologies/jira-linter) into this github-actions monorepo. It replaces the previously used third-party cyrus-za/jira-lint action with a new, in-house composite action built in Go.

The new implementation extracts a Jira ticket ID from the branch name or PR title, fetches the ticket details from the Jira API, updates the PR description with this information, and validates the ticket's status. The PR also introduces a new CI job for testing the Go application and updates the Dependabot configuration to scan for Go module dependencies.

Files Changed Analysis

• Added Files: The bulk of the changes involve the addition of the jira-linter/ directory. This new directory contains the entire Go application (main.go, config.go, main_test.go), its dependencies (go.mod, go.sum), documentation (README.md), and the composite action definition (action.yaml).
• Modified Files:
  • .github/workflows/jira-lint.yaml: The core workflow has been updated to use the new local composite action (./jira-linter) instead of the external one. The required secrets have also been changed.
  • .github/workflows/ci-test.yml: A new job, test-jira-linter, has been added to run go test on the new linter code. The existing test job was renamed for clarity.
  • .github/.dependabot.yml: Configuration was added to enable Dependabot to scan and update the Go modules in the jira-linter/ directory.
  • docs/workflows/jira-lint.md: The documentation was updated to reflect the new implementation, usage instructions, and required secrets.
  • .gitignore: Patterns for Go build artifacts and test files were added.

Architecture & Impact Assessment

• What this PR accomplishes: It internalizes a key piece of the PR validation process, centralizing its code and maintenance within the github-actions repository. This removes a third-party dependency and provides greater control over the Jira validation logic.

• Key technical changes introduced:

  • A new Go command-line application is introduced to handle all the logic for Jira and GitHub API interactions.
  • A composite action (jira-linter/action.yaml) orchestrates the setup, build, and execution of this Go application within the GitHub Actions environment.
  • The action posts sticky comments on PRs to provide clear feedback on validation failures.

• Affected system components: This change directly affects the PR validation workflow for all repositories using the jira-lint.yaml reusable workflow. The author notes that 20 repositories will need to update their workflow files to point to the new action path after this PR is merged, indicating a broad impact across the organization's projects.

• Workflow Visualization:

graph TD
    A[Pull Request Event] --> B{jira-lint.yaml Workflow};
    B --> C[Checkout github-actions repo];
    C --> D[Run ./jira-linter composite action];
    D --> E[Build & Execute Go App];
    E -->|Fetch issue| F[Jira API];
    E -->|Update PR & Post Comment| G[GitHub API];

Loading

Scope Discovery & Context Expansion

The scope of this PR is to replace an external Jira linting tool with a custom, self-contained solution. The core logic resides in jira-linter/cmd/linter/main.go and performs the following steps:

1. Loads configuration from environment variables (Jira URL, credentials, PR context).
2. Extracts a Jira issue ID (e.g., ABC-123) from the branch name or PR title.
3. Connects to the Jira API to fetch the issue's details (summary, status).
4. Validates the issue's status against a hardcoded list of accepted statuses (e.g., "In Dev", "In Code Review").
5. Connects to the GitHub API to update the pull request's description with a formatted block of Jira information.

The jira-linter/action.yaml file manages the execution flow, including building the Go binary, running it with the correct context, and using the marocchino/sticky-pull-request-comment action to manage failure/success comments. The impact is significant as it requires a coordinated migration across 20 repositories to adopt the new action path.

Metadata

• Review Effort: 4 / 5
• Primary Label: chore

---

Powered by Visor from Probelabs

Last updated: 2026-06-24T10:19:27.483Z | Triggered by: pr_updated | Commit: 6afc7ad

💡 TIP: You can chat with Visor using /visor ask <your question>

[probelabs]

Security Issues (2)

Severity	Location	Issue
🟠 Error	jira-linter/cmd/linter/main.go:312-323	Potential stored Cross-Site Scripting (XSS) vulnerability in the pull request description. The Jira issue summary (`issue.Fields.Summary`) and status (`issue.Fields.Status.Name`) are fetched from the Jira API and embedded directly into the PR description. A malicious Jira ticket summary or status containing an HTML payload (e.g., `<script>`) could be executed in the browser of users viewing the pull request, potentially leading to session hijacking. 💡 Suggestion HTML-escape the Jira summary and status name before embedding them in the PR description to prevent the browser from interpreting them as active content. Additionally, replace characters that could break the markdown table structure, such as pipe characters (`|`) and newlines.
🟠 Error	jira-linter/cmd/linter/main.go:359	Potential stored Cross-Site Scripting (XSS) vulnerability in the failure comment. When a Jira ticket has an invalid status, the status name from the Jira API is included raw in the error message. This error message is then posted in a PR comment inside a code block. A malicious status name containing markdown control characters (e.g., ```) could be used to break out of the code block and inject arbitrary HTML or markdown, leading to XSS. 💡 Suggestion Sanitize the Jira status name before including it in the error message. Remove or replace characters that have special meaning in markdown, such as backticks and newlines, to ensure the content remains safely within the code block in the GitHub comment.

Architecture Issues (2)

Severity	Location	Issue
🟡 Warning	jira-linter/action.yaml:1	The composite action lacks an input for customizing accepted Jira statuses, forcing all consumers to adhere to a hardcoded list ("in dev", "in code review", "ready for dev", etc.). The underlying Go binary supports customization via a `--statuses` flag, but this is not exposed. This limits the action's applicability for teams with different Jira workflows and is a regression from the previous action which supported status customization. 💡 Suggestion Add a new input, for example `accepted-statuses`, to `action.yaml`. Pass the value of this input to the `linter` command using the `--statuses` flag. Ensure it defaults to an empty string or the current default list to maintain backward compatibility for existing users.
🟡 Warning	jira-linter/cmd/linter/main.go:121-138	The validation logic in `validateBranchAndTitle` is more lenient than what is described in the documentation (`jira-linter/README.md`). The documentation states that the "PR title must contain the same Jira ticket ID as the branch," but the implementation only logs a warning if the IDs mismatch and does not fail the check. It also successfully passes if the ID is found only in the branch and not the title. This discrepancy can lead to confusion and inconsistent enforcement of repository standards. 💡 Suggestion Either update the documentation to reflect the lenient behavior (i.e., the ticket ID is sourced from the branch first, then the title, with a warning on mismatch) or modify the code to enforce the stricter rule. For stricter enforcement, the function should return an error if the ticket ID is missing from the title or if the IDs in the branch and title do not match.

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	jira-linter/action.yaml:13	The Jira linter Go application is compiled from source on every execution of the action. This adds overhead for setting up the Go toolchain and running `go install`, increasing workflow execution time. 💡 Suggestion To improve the action's startup time and reduce workflow execution minutes, consider pre-compiling the binary for the target architecture (linux/amd64) and committing it to the repository. The composite action can then execute the binary directly, removing the need for the 'Set up Go' and 'Build Jira Linter' steps.

---

Powered by Visor from Probelabs

Last updated: 2026-06-24T10:19:20.636Z | Triggered by: pr_updated | Commit: 6afc7ad

💡 TIP: You can chat with Visor using /visor ask <your question>

[rafalgolarz]

LGTM. I would probably move the regex outside the function but it still works, so 👍
Thanks