reapply gromit config to main

[Razeen-Abdal-Rahman]

Config files as setup in gromit, if there are changes that need to be made let me know. I will make the changes through gromit.

[probelabs]

This pull request overhauls the CI/CD release pipeline by applying a standardized "gromit" configuration. The changes introduce a more robust and comprehensive build, test, and release process for both the AI Studio application and a newly defined microgateway component.

Files Changed Analysis

This PR modifies four files, all related to the CI/CD process. The most significant changes are in .github/workflows/release.yml (+336/-97) and ci/goreleaser/goreleaser.yml (+91/-51), reflecting a major restructuring of the release workflow and build configuration. ci/Dockerfile.std and ci/install/post_install.sh receive minor corresponding adjustments.

Architecture & Impact Assessment

• What this PR accomplishes: This PR standardizes and significantly enhances the release workflow. It decouples the frontend build from the main Go build, introduces comprehensive packaging tests for Debian and RPM distributions, and configures distinct build processes for two separate applications: tyk-ai-studio and tyk-ai-microgateway.

• Key technical changes introduced:

  • Frontend Build Separation: A new ai-studio-frontend-build job is introduced in release.yml to build the UI, with its artifacts being passed to the subsequent goreleaser job.
  • Multi-Application Builds: The goreleaser.yml configuration is split to handle two distinct applications (std and microgateway), each with its own build IDs, packaging rules, and publishing configurations.
  • Enhanced Package Testing: New jobs (upgrade-deb, upgrade-rpm) are added to the workflow. These jobs test the installation of the generated .deb and .rpm packages on a matrix of different Linux distributions (Ubuntu, Debian, Rocky, Amazon Linux) and architectures (amd64, arm64).
  • Docker Build Refinements: The Docker build steps are expanded to build and push images for both std and microgateway applications to multiple registries (AWS ECR for CI, DockerHub/Cloudsmith for releases). The ci/Dockerfile.std is updated to use a newer Debian base image (trixie-slim).

• Affected system components: The primary impact is on the project's CI/CD and release engineering infrastructure. The process of creating, testing, and publishing official releases is fundamentally changed and automated to a higher degree.

Workflow Visualization

The new job dependencies in the release workflow can be visualized as follows:

graph TD
    subgraph "Release Workflow"
        A[ai-studio-frontend-build] --> B[goreleaser]
        B --> C[test-controller-distros]
        B --> D[sbom]
        C --> E[upgrade-deb]
        C --> F[upgrade-rpm]
    end

Loading

Scope Discovery & Context Expansion

The changes are contained within the CI/CD configuration files (.github/workflows/, ci/), but they reveal a broader architectural scope:

• Monorepo Structure: The goreleaser.yml changes, specifically the addition of a microgateway build with dir: microgateway, confirm that this repository is a monorepo containing at least two distinct Go applications: the main ai-studio and a microgateway.
• Deployment Targets: The addition of comprehensive testing for .deb and .rpm packages across various distributions indicates that native package installation is a primary deployment method alongside Docker containers.
• Release Process Maturity: The introduction of automated package testing, separate build configurations, and multi-registry publishing signifies a move towards a more mature and reliable automated release process.

Metadata

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

---

Powered by Visor from Probelabs

Last updated: 2025-11-26T11:23:19.436Z | Triggered by: pr_opened | Commit: fa90012

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

[probelabs]

Security Issues (3)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:343	The reusable workflow for SBOM generation is pinned to the `main` branch (`TykTechnologies/github-actions/.github/workflows/sbom.yaml@main`). This creates a supply chain risk, as any changes pushed to that branch will be automatically used, potentially introducing malicious code or breaking changes without review in this repository's context. 💡 Suggestion Pin the reusable workflow to a specific, immutable version, preferably a commit SHA, or at least a release tag (e.g., `@v1.2.3`). This ensures that the workflow is deterministic and secure.
🟡 Warning	ci/Dockerfile.std:3	The Dockerfile's base image has been changed to `debian:trixie-slim`. 'Trixie' is the current testing version of Debian and is not recommended for production use. Testing distributions are not as stable and may contain unpatched security vulnerabilities compared to the stable release. 💡 Suggestion Use the current stable version of Debian, which is `debian:bookworm-slim`, to ensure a secure and stable base for the production image.
🟡 Warning	.github/workflows/release.yml:257-303	The package installation test jobs use the `curl | bash` pattern to execute repository setup scripts from `packagecloud.io`. This is risky because a compromise of the remote server or a man-in-the-middle attack could lead to arbitrary code execution in the CI environment. This pattern is used for both .deb (line 257) and .rpm (line 303) setups. 💡 Suggestion For improved security, download the script first, then execute it. If possible, verify the script's integrity via a checksum or signature before execution. Alternatively, replicate the necessary setup steps from the script directly within the workflow file to avoid executing remote code.

Architecture Issues (4)

Severity	Location	Issue
🟠 Error	ci/goreleaser/goreleaser.yml:122-126	The packaging configuration (`nfpms`) no longer includes the example configuration file (`tyk-ai-studio.conf.example`), the default environment file (`/etc/default/tyk-ai-studio`), or the `templates` directory. Removing these files is a breaking change for users who rely on them for initial setup and configuration. It makes the application significantly harder to configure and use out-of-the-box. 💡 Suggestion Restore the missing files to the `contents` section for both the `std` and `microgateway` packages. If these files are intentionally obsolete due to a new configuration mechanism, this change must be clearly documented in the project's documentation and release notes to guide users through the new process.
🟠 Error	ci/goreleaser/goreleaser.yml:60	The `fips` build configuration and its corresponding `nfpm` packaging section have been completely removed. If FIPS compliance is a supported feature of this product, its removal constitutes a major feature regression that will impact users in regulated environments who depend on it. 💡 Suggestion If FIPS support is still a requirement for the product, the FIPS build and packaging configurations should be reinstated. If this feature is being intentionally deprecated, the decision should be clearly communicated to users and stakeholders.
🟢 Info	.github/workflows/release.yml:161-248	The Docker metadata generation and image push steps for the `microgateway` and `std` variants are nearly identical, leading to code duplication. Specifically, the `ci_metadata_microgateway` and `ci_metadata_std` steps, as well as their corresponding `build-push-action` steps for CI and production pushes, are repeated with only minor changes to names and labels. 💡 Suggestion To reduce duplication and improve maintainability, consider refactoring these steps using a matrix strategy within the `goreleaser` job. A matrix over the package variants (`[microgateway, std]`) would allow you to define the metadata and build steps once, using matrix variables for the parts that differ (e.g., image name, build arguments).
🟡 Warning	ci/Dockerfile.std:3	The Docker base image has been changed from `debian:bookworm-slim` (stable) to `debian:trixie-slim` (testing). Using a testing release for a production Docker image can introduce instability and unexpected breaking changes from upstream dependencies, as packages in 'trixie' are not yet considered stable. 💡 Suggestion Revert to using the latest stable Debian release (`debian:bookworm-slim`) unless there is a specific and compelling requirement for a package or feature that is only available in the 'trixie' release. Prioritizing stability is generally recommended for production artifacts.

Performance Issues (1)

Severity	Location	Issue
🟢 Info	.github/workflows/release.yml:70-342	The `goreleaser` job serially executes package building (using GoReleaser) and Docker image building/pushing. The subsequent testing jobs (`upgrade-deb`, `upgrade-rpm`) depend on the entire job's completion, including the time-consuming Docker operations, even though they only need the generated packages. This serial execution unnecessarily lengthens the critical path of the CI pipeline. 💡 Suggestion To optimize the workflow's execution time, separate the Docker image building and pushing logic into a new job. This new job can run in parallel with the package testing jobs. The current `goreleaser` job would be responsible only for building packages and uploading artifacts, allowing dependent jobs (testing and image building) to start earlier and run concurrently, reducing total wall-clock time.

Quality Issues (5)

Severity	Location	Issue
🔴 Critical	ci/goreleaser/goreleaser.yml:134-158	The `nfpms` configuration for the `std` package (`tyk-ai-studio`) is missing the `contents` section that includes the example configuration file (`tyk-ai-studio.conf.example`), default environment file (`/etc/default/tyk-ai-studio`), and templates (`templates/*`). These files were present in the previous configuration. Their absence will likely cause the application to fail at startup, as the Docker container's `CMD` points to a config file that will not exist. 💡 Suggestion Add the `contents` section back to the `nfpms` configuration for the `std` package, similar to how it was in the old configuration, to ensure all necessary files are included in the final package.
🟠 Error	.github/workflows/release.yml:334-378	The package upgrade test jobs (`upgrade-deb` and `upgrade-rpm`) suppress errors when attempting to install a previous version of the package by using `|| echo "..."`. This makes the test unreliable, as any genuine failure during this step (e.g., repository misconfiguration, network issues) will be silently ignored, potentially giving a false positive test result. 💡 Suggestion Instead of suppressing errors, check if the previous package version exists before attempting installation. If it doesn't, skip the step with a notice. If it does exist and fails to install, the job should fail to indicate a problem.
🟡 Warning	.github/workflows/release.yml:381	The `upgrade-rpm` test job uses `rpm -Uvh --force` to install the package. The `--force` flag can mask important issues such as file conflicts or dependency problems, allowing the test to pass even if the package would fail to install in a real-world scenario. Tests should mimic production installations as closely as possible. 💡 Suggestion Remove the `--force` flag from the `rpm -Uvh` command to ensure the test accurately reflects a standard package installation and catches potential conflicts.
🟡 Warning	.github/workflows/release.yml:41	The frontend build job sets `CI=false`. For many frontend build tools, such as Create React App, `CI=true` enables stricter checks and treats warnings as errors. Building with `CI=false` may hide potential issues in the frontend code that should be addressed. 💡 Suggestion Set `CI=true` to enforce stricter build checks, or remove the `CI` environment variable to use the default behavior of the CI environment, which is typically `true`.
🟡 Warning	ci/Dockerfile.std:29-30	There is a naming inconsistency in the Dockerfile. The `ENTRYPOINT` uses the binary `ai-studio`, while the `CMD` refers to a configuration file named `tyk-ai-studio.conf`. This inconsistency can be confusing for users and maintainers. A consistent naming scheme for the application binary, configuration files, and directories should be used. 💡 Suggestion Consider renaming the configuration file to `ai-studio.conf` to match the binary name for better consistency. This change would need to be reflected in the packaging configuration (`goreleaser.yml`) and installation scripts as well.

---

Powered by Visor from Probelabs

Last updated: 2025-11-26T11:23:22.585Z | Triggered by: pr_opened | Commit: fa90012

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

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Gromit seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}