Gromit sync with tyk repo TT-16131

[Razeen-Abdal-Rahman]

Description

Carry over changes from gromit into the tyk repo

Related Issue

TT-16131

Motivation and Context

Ensure the tyk repo is in sync as the buildenv for this repo will continue to be 1.24-bullseye with the addition of a manual pull of the latest go version, this is done upstream when the image is built.
This PR carries over other changes from gromit ensuring everything is in sync after this change.

[github-actions]

API Changes

no api changes detected

[probelabs]

🔍 Code Analysis Results

This PR synchronizes the Tyk repository with changes from an upstream source, introducing a FIPS-compliant build variant for the Tyk Gateway and enhancing the CI/CD pipeline's robustness.

Files Changed Analysis

• .github/workflows/release.yml: The release workflow is significantly updated to introduce a dedicated build-and-push process for a new FIPS Docker image (tyk-gateway-fips) using docker/build-push-action. The main goreleaser job is now configured to skip Docker builds. Additionally, the upgrade test steps for DEB and RPM packages are made more resilient, preventing CI failures if older package versions are unavailable.
• ci/goreleaser/goreleaser.yml: This file contains the core change for FIPS compliance, adding the GOEXPERIMENT=boringcrypto environment variable to the build process. This instructs the Go compiler to use the FIPS 140-2 validated BoringCrypto module.
• ci/install/post_install.sh: The post-installation script has been improved for robustness. It now correctly handles the cleanup of systemd vs. init.d service files and checks if tyk.conf exists before attempting to set its permissions.
• ci/Dockerfile.std: Contains minor refactoring, reordering layers to improve Docker build caching efficiency.

Architecture & Impact Assessment

• What this PR accomplishes: It introduces the capability to produce and release a FIPS-compliant version of the Tyk Gateway, delivered as a new Docker image (tykio/tyk-gateway-fips). This addresses the needs of users in regulated environments requiring FIPS 140-2 validated cryptography.
• Key technical changes introduced:
  1. FIPS Compliance: Enables boringcrypto at compile time via the GOEXPERIMENT flag.
  2. CI/CD Pipeline: Adds a new workflow path for building and publishing the FIPS Docker image to both CI and production registries.
  3. Build Process Refactoring: Decouples Docker image creation from GoReleaser, handling it directly within the GitHub Actions workflow.
  4. CI Resilience: Modifies upgrade tests to continue even if older package versions can't be fetched, preventing the pipeline from failing.
• Affected system components: The changes are primarily confined to the build, packaging, and CI/CD release pipeline. The resulting FIPS binary will use a different set of cryptographic libraries (BoringSSL), which could have performance implications for crypto-heavy operations. The core application logic remains unchanged.

graph TD
    subgraph "Release Workflow"
        A[Start Build Job] --> B{Build Matrix};
        B --> C_EE[Build & Push EE Image];
        B --> C_STD[Build & Push STD Image];
        B --> C_FIPS["Build & Push FIPS Image (New)"];
        C_EE & C_STD --> D[Run Upgrade Tests];
    end

Loading

Scope Discovery & Context Expansion

The scope is focused on the build and release process to introduce a new FIPS build variant. Enabling boringcrypto is a standard method in the Go ecosystem for achieving FIPS compliance. This change creates a new build artifact without altering existing ones, minimizing regression risk for standard builds.

The broader context is to support customers with stringent regulatory requirements. The creation of a new tyk-gateway-fips image implies that downstream tooling, such as the Tyk Helm charts and Tyk Operator, will likely require updates to allow users to deploy this new variant. The changes to the upgrade tests represent a pragmatic trade-off, improving CI stability at the cost of slightly reduced strictness in testing the upgrade path from specific older versions.

Metadata

• Review Effort: 3 / 5
• Primary Label: enhancement

---

Powered by Visor from Probelabs

Last updated: 2025-11-18T13:53:41.335Z | Triggered by: synchronize | Commit: a57cbbc

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

[probelabs]

🔍 Code Analysis Results

Security Issues (2)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:490-491	Error suppression in the Debian upgrade test pipeline using `|| echo` can mask legitimate installation failures. This may cause upgrade tests to be skipped silently, preventing the detection of regressions in the upgrade process, which could have security implications. The current implementation hides errors from `curl`, `bash`, and `apt-get`. 💡 Suggestion Fail the CI job on unexpected errors. If the goal is to handle cases where a previous version is not found, explicitly check for the 'package not found' error from `apt-get` and only then proceed. Other errors (e.g., from `curl` or repository setup) should cause the job to fail to ensure pipeline integrity.
🟡 Warning	.github/workflows/release.yml:549-550	Error suppression in the RPM upgrade test pipeline using `|| echo` can mask legitimate installation failures. This may cause upgrade tests to be skipped silently, preventing the detection of regressions in the upgrade process, which could have security implications. The current implementation hides errors from `curl`, `bash`, and `yum`. 💡 Suggestion Fail the CI job on unexpected errors. If the goal is to handle cases where a previous version is not found, explicitly check for the 'package not found' error from `yum` and only then proceed. Other errors (e.g., from `curl` or repository setup) should cause the job to fail to ensure pipeline integrity.

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:200-265	The newly added steps for building and pushing the FIPS Docker image are a near-exact copy of the existing steps for the `ee` (lines 131-197) and `std` (lines 268-334) images. This introduces significant code duplication into the CI/CD pipeline, making it harder to maintain and increasing the risk of inconsistencies. A change in the build process would need to be replicated in three places. 💡 Suggestion To adhere to the DRY (Don't Repeat Yourself) principle, refactor the common Docker build-and-push logic into a reusable GitHub Actions workflow (`workflow_call`) or a composite action. This reusable component can then be called three times with different parameters for each image variant (`ee`, `fips`, `std`), such as the image name, build arguments, and labels. This will simplify the main workflow and centralize the build logic.

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	ci/goreleaser/goreleaser.yml:69	The build process now enables `GOEXPERIMENT=boringcrypto`, which substitutes the standard Go cryptographic libraries with the FIPS-compliant BoringCrypto library. This change can alter the performance characteristics of cryptographic operations, such as TLS termination, JWT validation, and request signing, potentially leading to performance regressions in CPU-bound workloads. 💡 Suggestion It is recommended to conduct performance benchmarks on critical paths involving cryptographic functions to quantify the impact of this change. This will validate that the switch to BoringCrypto does not introduce unacceptable performance degradation for the gateway's typical workload.

Quality Issues (2)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:428-429	In the `test-deb-package` job, both the package repository setup and the installation of the previous version for upgrade testing are configured to continue on failure. This can silently disable the upgrade test path if there are persistent issues with the package repository, leading to a false sense of security. The job will still report success, having only tested a fresh installation. 💡 Suggestion To make failures more visible without failing the build, consider using a GitHub Actions workflow command to create a warning annotation. For example: `curl ... | bash || (echo '::warning::DEB repository setup failed. Skipping upgrade test.' && exit 0)`. This would make the skipped test explicit in the build logs and UI. If the upgrade test is considered critical, these commands should be allowed to fail the job.
🟡 Warning	.github/workflows/release.yml:484-485	In the `test-rpm-package` job, both the package repository setup and the installation of the previous version for upgrade testing are configured to continue on failure. This can silently disable the upgrade test path if there are persistent issues with the package repository, leading to a false sense of security. The job will still report success, having only tested a fresh installation. 💡 Suggestion To make failures more visible without failing the build, consider using a GitHub Actions workflow command to create a warning annotation. For example: `curl ... | bash || (echo '::warning::RPM repository setup failed. Skipping upgrade test.' && exit 0)`. This would make the skipped test explicit in the build logs and UI. If the upgrade test is considered critical, these commands should be allowed to fail the job.

Dependency Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:201-266	The introduction of the `tyk-gateway-fips` Docker image creates a new deployment variant that requires corresponding updates in downstream deployment tools. The `tyk-charts` and `tyk-operator` repositories must be updated to allow users to select and configure this FIPS-compliant image. This PR is not linked to any changes in those repositories, which could leave the new feature undeployable through standard methods. 💡 Suggestion Ensure that corresponding pull requests or tickets are created and linked for `tyk-charts` and `tyk-operator` to add support for deploying the `tyk-gateway-fips` image. This typically involves adding new values to the Helm chart and updating the operator's logic to handle the new image variant.

✅ Connectivity Check Passed

No connectivity issues found – changes LGTM.

---

Powered by Visor from Probelabs

Last updated: 2025-11-18T13:53:42.600Z | Triggered by: synchronize | Commit: a57cbbc

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

[github-actions]

🚨 Jira Linter Failed

Commit: a57cbbc
Failed at: 2025-11-18 13:50:21 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: branch name 'releng/master' must contain 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 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

[Razeen-Abdal-Rahman]

/release to release-5.8

[probelabs]

✅ Cherry-pick successful. A PR was created: #7550

[Razeen-Abdal-Rahman]

/release to release-5.10

[probelabs]

✅ Cherry-pick successful. A PR was created: #7551

[Razeen-Abdal-Rahman]

/release to release-5.10.1

[probelabs]

✅ Cherry-pick successful. A PR was created: #7552