Merging to release-5.13.1: [TT-17507] Move jira-linter into github-actions mono-repo (#8366)

[probelabs]

TT-17507 Move jira-linter into github-actions mono-repo (#8366)

Follow up PR for
TykTechnologies/github-actions#138

Ticket Details

TT-17507

Status	In Code Review
Summary	Move jira-linter to github-actions

Generated at: 2026-07-02 14:14:48

[sentinelone-cnapp-eu1]

SentinelOne CNS Hardcoded Secret Detector
✅ Congratulations, your code is safe

SentinelOne CNS is a cloud-agnostic, agentless CSPM & CWPP solution that continuously detects and prevents vulnerabilities that have the highest probability of being exploited in Azure, AWS, Google Cloud, and Kubernetes.

[github-actions]

🚨 Jira Linter Failed

Commit: d2c07e5
Failed at: 2026-07-09 11:24:12 UTC

The Jira linter failed to validate your PR. Please check the error details below:

🔍 Click to view error details

failed to get Jira issue: Jira issue RELEASE-5 not found (HTTP 404). The issue may exist but the API token may lack permission to access it. Verify that the token owner has access to the project and that JL_JIRA_BASEURL (https://api.atlassian.com/ex/jira/c25a3295-62f6-4d5a-8ddd-58122b144a37) is correct

Next Steps

• Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
• Verify your PR title matches the branch's Jira ticket ID
• Check that the Jira ticket exists and is accessible

---

This comment will be automatically deleted once the linter passes.

[probelabs]

This PR updates the jira-pr-validator.yaml workflow to use the new, centralized jira-linter GitHub Action from the TykTechnologies/github-actions mono-repo. This change is part of a broader initiative to consolidate shared CI/CD tooling for better maintainability.

Files Changed Analysis

The change is confined to a single CI workflow configuration file, .github/workflows/jira-pr-validator.yaml. The modifications involve:

• Updating the uses directive from TykTechnologies/jira-linter@... to TykTechnologies/github-actions/jira-linter@production.
• Changing the input parameters for Jira authentication, replacing JIRA_USER_EMAIL and JIRA_TOKEN with JIRA_BASE_URL and JIRA_READ_AUTH secrets.

Architecture & Impact Assessment

• What this PR accomplishes: It aligns this repository's CI process with the new standard of using a mono-repo for shared GitHub Actions, specifically for Jira ticket validation on pull requests.

• Key technical changes introduced: The workflow now points to a different repository for the jira-linter action and uses a revised set of secrets for authentication. This centralizes the action's code, making updates and maintenance more efficient.

• Affected system components: The only affected component is the developer CI pipeline. There is no impact on the application's runtime code or its architecture. The successful execution of the jira-pr-validator job is dependent on the new secrets (JIRA_BASE_URL, JIRA_READ_AUTH) being available in the repository's settings.

• Dependency Change Visualization:

  graph TD
      subgraph Before
          A["jira-pr-validator.yaml"] -- uses --> B["TykTechnologies/jira-linter (Repo)"];
      end
      subgraph After
          C["jira-pr-validator.yaml"] -- uses --> D["TykTechnologies/github-actions (Mono-repo)"];
          D -- contains --> E["jira-linter (Action)"];
      end
  

  Loading

Scope Discovery & Context Expansion

• Broader Scope: This change is part of a larger, organization-wide migration (TT-17507) to consolidate multiple standalone GitHub Actions into a single mono-repo. Other repositories using the old TykTechnologies/jira-linter will likely require similar updates.
• Next Steps for Verification: To ensure this change works as expected, one would need to verify that the JIRA_BASE_URL and JIRA_READ_AUTH secrets have been configured correctly in this repository's GitHub secrets settings. Without these, the workflow will fail at the Jira validation step.

Metadata

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

---

Powered by Visor from Probelabs

Last updated: 2026-07-09T11:24:55.782Z | Triggered by: pr_opened | Commit: d2c07e5

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

[probelabs]

Security Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/jira-pr-validator.yaml:17	The GitHub Action `TykTechnologies/github-actions/jira-linter` is referenced using a mutable tag (`production`). This practice can introduce a supply chain vulnerability if the tag is updated with malicious code. An attacker who compromises the source repository could inject malicious code into the workflow. 💡 Suggestion Pin the action to a specific, immutable commit SHA instead of a branch or tag. This ensures that the workflow runs a verified version of the action. For example, if the latest commit on `production` is `f20ba226415b6ffd37e1872c4e6d92bd83c002f0`, the line should be changed to `uses: TykTechnologies/github-actions@f20ba22`.

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/jira-pr-validator.yaml:18	The GitHub Action `TykTechnologies/github-actions/jira-linter` is pinned to the mutable `production` tag. Using a floating tag can introduce unexpected breaking changes into the CI pipeline, making builds less reproducible and potentially causing failures without any changes in this repository. The previous implementation used a specific commit hash, which is a safer and more stable approach. 💡 Suggestion To ensure workflow stability and reproducibility, pin the action to an immutable version. The most stable approach is to use a specific commit SHA. Alternatively, use a specific version tag (e.g., `v1.2.3`) if the action's repository follows semantic versioning.

Security Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/jira-pr-validator.yaml:17	The GitHub Action `TykTechnologies/github-actions/jira-linter` is referenced using a mutable tag (`production`). This practice can introduce a supply chain vulnerability if the tag is updated with malicious code. An attacker who compromises the source repository could inject malicious code into the workflow. 💡 Suggestion Pin the action to a specific, immutable commit SHA instead of a branch or tag. This ensures that the workflow runs a verified version of the action. For example, if the latest commit on `production` is `f20ba226415b6ffd37e1872c4e6d92bd83c002f0`, the line should be changed to `uses: TykTechnologies/github-actions@f20ba22`.

\n\n ### Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/jira-pr-validator.yaml:18	The GitHub Action `TykTechnologies/github-actions/jira-linter` is pinned to the mutable `production` tag. Using a floating tag can introduce unexpected breaking changes into the CI pipeline, making builds less reproducible and potentially causing failures without any changes in this repository. The previous implementation used a specific commit hash, which is a safer and more stable approach. 💡 Suggestion To ensure workflow stability and reproducibility, pin the action to an immutable version. The most stable approach is to use a specific commit SHA. Alternatively, use a specific version tag (e.g., `v1.2.3`) if the action's repository follows semantic versioning.

\n\n ### Performance Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/jira-pr-validator.yaml:18	The workflow uses a mutable reference '@production' for the 'TykTechnologies/github-actions/jira-linter' action. This can introduce performance variability in the CI pipeline if the action at the 'production' tag/branch is updated with a slower version. Pinning to a specific commit SHA ensures reproducible and predictable performance. 💡 Suggestion To ensure consistent performance and prevent unexpected slowdowns in the CI/CD pipeline, replace the mutable '@production' tag with a specific commit SHA for the GitHub Action. You can find the latest commit SHA on the 'production' branch of the 'TykTechnologies/github-actions' repository.

---

Powered by Visor from Probelabs

Last updated: 2026-07-09T11:24:52.448Z | Triggered by: pr_opened | Commit: d2c07e5

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

[sonarqubecloud]

Quality Gate failed

Failed conditions
C Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

💡 Need a hand with PR review? Try Gitar by Sonar!