[TT-15867] rollout new Jira linter

[bsten-tyk]

Ticket Details

TT-15867

Status	In Code Review
Summary	Rollout the tool across repositories

Generated at: 2025-10-20 11:41:09

[netlify]

✅ Deploy Preview for nifty-johnson-6002dd ready!

Name	Link
🔨 Latest commit	a5f73db
🔍 Latest deploy log	https://app.netlify.com/projects/nifty-johnson-6002dd/deploys/68f61fb73ce1220008edd713
😎 Deploy Preview	https://deploy-preview-409--nifty-johnson-6002dd.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[probelabs]

🔍 Code Analysis Results

This PR introduces a new GitHub Actions workflow to validate pull request titles against Jira tickets, ensuring that all changes are properly tracked.

Files Changed Analysis

• .github/workflows/jira-pr-validator.yaml: A new workflow file has been added. It contains 21 lines of configuration for the "Validate PR against Jira" action. This is the only file changed in this pull request.

Architecture & Impact Assessment

• What this PR accomplishes: It automates the validation of pull request titles against Jira, enforcing a standard process for linking code changes to project management tickets.
• Key technical changes introduced: A new CI workflow is added that integrates with Jira via the TykTechnologies/jira-linter GitHub action. It runs on pull request events and relies on a JIRA_TOKEN repository secret for authentication.
• Affected system components: This change affects the repository's CI/CD pipeline and the pull request process for all contributors. It introduces a new status check that must pass for non-draft pull requests. The application's runtime code is not affected.

Here is a diagram illustrating the workflow logic:

graph TD
    A[Developer opens/updates a PR] --> B{Is PR a draft?};
    B -- Yes --> C[Workflow Skipped];
    B -- No --> D[Trigger 'Validate PR against Jira' workflow];
    D --> E[Run 'TykTechnologies/jira-linter' action];
    E --> F{Validate PR against Jira ticket};
    F -- Success --> G[PR check passes];
    F -- Failure --> H[PR check fails];

Loading

Scope Discovery & Context Expansion

The impact of this PR is confined to the repository's development workflow. The core validation logic is handled by the external TykTechnologies/jira-linter action. For this workflow to function correctly, a repository administrator must configure the JIRA_TOKEN secret in the repository settings.

A potential improvement would be to pin the action to a specific version (e.g., @v1) instead of @main to prevent unexpected changes from the action's repository from breaking the workflow.

Metadata

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

---

Powered by Visor from Probelabs

Last updated: 2025-10-20T11:43:11.684Z | Triggered by: synchronize | Commit: a5f73db

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

[probelabs]

🔍 Code Analysis Results

Security Issues (2)

Severity	Location	Issue
🟠 Error	.github/workflows/jira-pr-validator.yaml:18	The workflow uses `TykTechnologies/jira-linter@main`, which points to the latest commit on the `main` branch. This is a security risk because any changes pushed to that branch, whether malicious or breaking, will be automatically used by this workflow. If the action's repository is compromised, it could lead to the execution of arbitrary code and the exposure of secrets, such as the `JIRA_TOKEN`. 💡 Suggestion To ensure the workflow uses a stable and trusted version of the action, pin it to a specific commit SHA or a release tag. For example, using a commit SHA: uses: TykTechnologies/jira-linter@a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2 Or using a specific release tag: uses: TykTechnologies/jira-linter@v1.2.3
🟡 Warning	.github/workflows/jira-pr-validator.yaml:13	The workflow does not specify `permissions` for the `GITHUB_TOKEN`. By default, the token is granted broad permissions, including write access to the repository contents. This violates the principle of least privilege. If any step in this job were compromised (e.g., through the unpinned action), it could abuse these permissions to alter the repository. 💡 Suggestion Explicitly define the minimum required permissions for the job. If the linter only needs to read pull request data and post status checks or comments, configure the permissions accordingly. Add a permissions block to the validate job: jobs: validate: if: ${{ !github.event.pull_request.draft }} runs-on: ubuntu-latest permissions: contents: read pull-requests: write steps: - name: Validate Jira ticket uses: TykTechnologies/jira-linter@main # ... Adjust the permissions based on the exact needs of the jira-linter action.

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/jira-pr-validator.yaml:18	The workflow uses `TykTechnologies/jira-linter@main`, which pins the action to the `main` branch. This is not a stable reference and can cause the workflow to fail unexpectedly if breaking changes are pushed to the `main` branch of the action's repository. This makes the build non-deterministic and can introduce security vulnerabilities or breaking changes without notice. 💡 Suggestion To ensure stability and predictability, pin the action to a specific version tag (e.g., `@v1`) or a commit SHA. If version tags are available for the `TykTechnologies/jira-linter` action, prefer using them.

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/jira-pr-validator.yaml:17	The workflow uses a GitHub Action pinned to the `main` branch (`TykTechnologies/jira-linter@main`). Using a mutable reference like a branch name for a third-party action can lead to unpredictable CI performance and stability. Future updates to the `main` branch of the action could introduce performance regressions, breaking changes, or security vulnerabilities without any corresponding change in this repository, making builds non-deterministic. 💡 Suggestion Pin the action to a specific immutable version, preferably a commit SHA or at least a specific version tag (e.g., `v1.2.3`). This ensures that the workflow uses a consistent, vetted version of the action, leading to more predictable performance and improved security. Example: uses: TykTechnologies/jira-linter@v1.0.0 # Or a specific commit SHA

Quality Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/jira-pr-validator.yaml:18	The GitHub Action `TykTechnologies/jira-linter` is pinned to the `main` branch. Using a floating reference like a branch name can introduce unexpected breaking changes into the workflow if the `main` branch is updated. This can lead to workflow failures without any changes in this repository. 💡 Suggestion For stability and reproducibility, it is recommended to pin the action to a specific commit SHA or a release tag (e.g., `@v1.0.0`). 🔧 Suggested Fix uses: TykTechnologies/jira-linter@<specific-tag-or-commit-sha>

Style Issues (1)

Severity	Location	Issue
🟢 Info	.github/workflows/jira-pr-validator.yaml:18	The GitHub Action `TykTechnologies/jira-linter` is pinned to the `main` branch. While this may be acceptable for internally managed actions, it is a best practice to pin actions to a specific version tag (e.g., `@v1`) or a commit SHA. This prevents unexpected workflow failures due to breaking changes being pushed to the `main` branch. 💡 Suggestion For improved stability and reproducibility, consider pinning the action to a specific release tag if available. For example: `uses: TykTechnologies/jira-linter@v1`.

---

Powered by Visor from Probelabs

Last updated: 2025-10-20T11:43:12.826Z | Triggered by: synchronize | Commit: a5f73db

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

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud