[releng master] gromit: sync templates

[probelabs]

Auto-generated from gromit templates by policy sync.

[probelabs]

This pull request, generated by the gromit policy sync tool, standardizes and hardens the CI/CD pipeline by aligning it with centralized templates.

Files Changed Analysis

• .github/workflows/drift-check.yml (New): A new workflow is introduced to detect and prevent manual modifications to files managed by the policy tool, ensuring CI configurations remain synchronized with their templates.
• .github/workflows/release.yml (Modified): This core workflow has been significantly refactored. The bespoke upgrade-deb and upgrade-rpm jobs, spanning over 100 lines, have been replaced by a single, reusable upgrade-tests workflow. Additionally, new validation steps have been added to:
  1. Ensure the Go version used in the build container is the latest available patch release.
  2. More robustly verify that all Docker image layers are gzip-compressed, now with support for multi-arch image manifests.
• ci/Dockerfile.distroless & ci/Dockerfile.std (Modified): Minor changes were made to quote variables in dpkg commands for better script robustness. The distroless Dockerfile also removes the explicit creation of the middleware/bundles directory.

Architecture & Impact Assessment

• What this PR accomplishes: It replaces repository-specific CI logic with standardized, reusable components. This reduces maintenance overhead, hardens the build process with new validation checks, and improves consistency across projects.
• Key technical changes introduced:
  • CI Abstraction: Replaced inline upgrade testing scripts with calls to a centralized, reusable GitHub Actions workflow (upgrade-tests.yml).
  • Build Hardening: Added proactive checks for Go compiler versions and Docker image layer compression to catch common release issues early.
  • Configuration Governance: Introduced a drift-check workflow to enforce CI configuration standards.
• Affected system components: The changes are confined to the CI/CD pipeline and have no impact on the runtime behavior or architecture of the Tyk Identity Broker application.

graph TD
    subgraph "CI Workflow Evolution"
        direction LR
        subgraph "Before"
            A[Custom Script: Get Distros] --> B(Job: upgrade-deb)
            A --> C(Job: upgrade-rpm)
        end
        subgraph "After"
            D["Reusable Action: distro-matrix"] --> E["Reusable Workflow: upgrade-tests"]
        end
        Before --|Refactored to|--> After
    end

Loading

Scope Discovery & Context Expansion

• The adoption of reusable workflows from the TykTechnologies/github-actions repository indicates a broader, organization-wide initiative to standardize CI/CD practices.
• The new scripts for Go validation and Docker layer inspection are currently implemented inline. The layer-checking script, in particular, is duplicated within the release.yml workflow and could be a candidate for extraction into its own reusable composite action to adhere to DRY principles.

Metadata

• Review Effort: 3 / 5
• Primary Label: n/a

---

Powered by Visor from Probelabs

Last updated: 2026-07-21T09:02:51.798Z | Triggered by: pr_updated | Commit: 7deb3ea

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

[probelabs]

Security Issues (1)

Severity	Location	Issue
🟠 Error	.github/workflows/drift-check.yml:9	Reusable workflows and actions are not pinned to a commit SHA, creating a supply chain risk. The `uses` clauses reference a mutable tag '@production'. If the 'production' tag is compromised or updated with malicious code in the source repository, this workflow will execute it. This issue is present for `drift-check.yml` on line 9, and in `.github/workflows/release.yml` for `distro-matrix` (line 302) and `upgrade-tests` (line 396). 💡 Suggestion Pin all reusable workflows and actions to a specific, immutable commit SHA. Find the latest commit SHA for the 'production' branch/tag in the `TykTechnologies/github-actions` repository and replace `@production` with the full SHA to ensure the executed code is immutable and auditable.

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:187-220	The shell function `verify_manifest` and its surrounding logic for checking Docker layer compression is duplicated. The exact same script block is used for the `std` image (lines 187-220) and the `distroless` image (lines 224-257). 💡 Suggestion To adhere to the DRY (Don't Repeat Yourself) principle and improve maintainability, this duplicated script logic should be extracted into a reusable component. A composite GitHub Action within the local repository (e.g., in a `.github/actions/` directory) would be an ideal solution. The workflow could then call this action twice with the respective image tags as input, centralizing the verification logic.

Quality Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:187-221	The shell script logic for verifying Docker image layer compression is duplicated. The same script block appears in the `build-distroless` job (lines 187-221) and the `build-std` job (lines 234-268). This violates the DRY principle, making the workflow harder to maintain as any changes to the logic must be synchronized in both places. 💡 Suggestion To improve maintainability, extract the duplicated script into a reusable composite action within the `.github/actions/` directory. This action can then be called from both jobs, passing the image tag as an input parameter.

---

Powered by Visor from Probelabs

Last updated: 2026-07-21T09:02:31.795Z | Triggered by: pr_updated | Commit: 7deb3ea

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

[github-actions]

🚨 Jira Linter Failed

Commit: 7deb3ea
Failed at: 2026-07-21 09:01:20 UTC

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

🔍 Click to view error details

failed to validate branch and PR title rules: neither branch name 'releng/master' nor PR title '[releng master] gromit: sync templates' contains a valid Jira ticket ID (e.g., ABC-123)

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.

[sonarqubecloud]

Quality Gate failed

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

See analysis details on SonarQube Cloud

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