[TT-15971]Add cross-repo dashboard build workflow for API tests

[jeffy-mathew]

Summary

This PR implements intelligent dashboard image resolution for API tests, enabling tests to run even when no matching tyk-analytics branch exists.

Changes

New Jobs Added

1. resolve-dashboard-image

Determines which dashboard image to use based on multiple criteria:

• Strategy 1 (no-relevant-changes): If PR has no changes in relevant packages (pkg, apidef, lib, common, certs, log, config, test, user, header), use gromit default
• Strategy 2 (gromit-branch): If matching branch exists in tyk-analytics, use gromit policy matching
• Strategy 3 (ecr-image): If ECR image exists with commit SHA, reuse existing image
• Strategy 4 (build-required): Build dashboard from target branch with PR gateway ref

2. build-dashboard-image (Conditional)

Only runs when needs_build=true:

• Checks out tyk-analytics on target branch
• Updates gateway dependency to PR commit SHA
• Builds dashboard binary with goreleaser
• Builds and pushes Docker image to ECR

Modified Jobs

api-tests

• Added dependency on resolve-dashboard-image
• Updated env-up action to use branch feat/TT-15971/add-dashboard-image-input
• Passes resolved dashboard image to env-up action

Benefits

✅ PRs without matching dashboard branches can now build custom dashboard automatically
✅ Reuses existing ECR images when available (faster CI)
✅ Smart package detection - only builds when changes affect relevant packages
✅ Backward compatible - existing workflows continue to work unchanged
✅ No false positives - workflow/docs/test-only changes don't trigger builds

Testing Strategy

The workflow intelligently handles different scenarios:

1. PR with matching tyk-analytics branch → Uses gromit policy (fast ⚡)
2. PR with no relevant package changes → Uses gromit default (fast ⚡)
3. PR with ECR image already built → Reuses existing image (fast ⚡)
4. PR needs custom dashboard → Builds dashboard from target branch (~10-15 min)

Related

Related to: TT-15971

Ticket Details

TT-15971

Status	In Code Review
Summary	Cross-Repository Dashboard Build & Testing

Generated at: 2025-11-25 16:46:32

[github-actions]

API Changes

--- prev.txt	2025-11-17 12:18:32.071548708 +0000
+++ current.txt	2025-11-17 12:18:22.007529054 +0000
@@ -12681,10 +12681,12 @@
 
 package crypto // import "github.com/TykTechnologies/tyk/pkg/alias/crypto"
 
+Package crypto provides alias exports for internal crypto utilities.
 
 VARIABLES
 
 var (
+	// HashStr provides string hashing functionality
 	HashStr = crypto.HashStr
 )
 # Package: ./pkg/alias/gateway

[probelabs]

🔍 Code Analysis Results

This PR introduces a sophisticated CI workflow to automatically build a compatible tyk-analytics (Dashboard) Docker image for API tests. This enables testing of tyk (Gateway) pull requests that may contain breaking changes for the Dashboard, without requiring a corresponding branch in the tyk-analytics repository.

Files Changed Analysis

The vast majority of changes are in .github/workflows/release.yml (+378/-1 lines), which implements the new CI logic. The minor changes in gateway/policy.go (import reordering) and pkg/alias/crypto/crypto.go (comment addition) appear to be unrelated code cleanup.

Architecture & Impact Assessment

This PR automates on-demand, cross-repository dependency building within the CI pipeline.

• What this PR accomplishes: It allows the api-tests to run with a custom-built Dashboard image that is compiled against the Gateway code from the PR. This solves the problem of testing breaking changes that span both repositories.
• Key technical changes introduced:
  1. resolve-dashboard-image job: A new workflow job that intelligently determines if a custom Dashboard build is needed. It uses a multi-step strategy: checking for changes in relevant Gateway packages (pkg, apidef, etc.), checking for a matching branch in tyk-analytics, and checking for a pre-existing image in ECR for the PR.
  2. build-dashboard-image job: A new conditional job that, when triggered, checks out the tyk-analytics repository, updates its go.mod to use the Gateway code from the PR's branch, builds a new Dashboard binary, and pushes a tagged Docker image to AWS ECR.
  3. api-tests job modification: The existing api-tests job is updated to depend on the new jobs and consume the dynamically provided Dashboard image URL.
• Affected system components: The primary impact is on the CI/CD pipeline for pull requests. It introduces a new build-time dependency on the tyk-analytics source code and a runtime dependency on AWS ECR for storing the custom-built images.

Workflow Visualization

graph TD
    A[PR Opened/Updated] --> B(goreleaser);
    B --> C[resolve-dashboard-image];

    subgraph "Image Resolution Strategy"
        C --> D{Relevant package changes?};
        D -- Yes --> J[Strategy: build-required];
        D -- No --> E{Matching branch in tyk-analytics?};
        E -- Yes --> F[Strategy: gromit-branch];
        E -- No --> G{ECR image for PR exists?};
        G -- Yes --> H[Strategy: reuse-pr-image];
        G -- No --> I[Strategy: gromit-default];
    end

    J --> K(build-dashboard-image);

    subgraph "API Testing"
        L[api-tests]
    end

    C -- image resolution info --> L;
    K -- optional built image --> L;
    F --> L;
    H --> L;
    I --> L;

Loading

Scope Discovery & Context Expansion

• Cross-Repository Dependencies: This workflow creates a tight coupling with TykTechnologies/tyk-analytics for the build process and TykTechnologies/github-actions for the test setup action. The PR uses a feature branch (...env-up@feat/TT-15971/add-dashboard-image-input) from the github-actions repository, which must be merged and the reference updated to a commit SHA before this PR can be merged.
• Maintenance Overhead: The hardcoded list of RELEVANT_PACKAGES in the workflow will require maintenance as the Gateway's internal structure evolves. An outdated list could lead to either unnecessary builds or, more critically, missed builds, resulting in CI failures.
• Image Tagging Strategy: The current strategy tags images with just the PR number (e.g., tyk-7517). This is not immutable; if a PR is updated with new commits, the tag remains the same, potentially causing tests to run against a stale Dashboard image. A more robust strategy would include the commit SHA in the tag to ensure test runs are deterministic.

Metadata

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

---

Powered by Visor from Probelabs

Last updated: 2025-11-17T12:19:49.608Z | Triggered by: synchronize | Commit: 64eff4c

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

[probelabs]

🔍 Code Analysis Results

Security Issues (3)

Severity	Location	Issue
🔴 Critical	.github/workflows/release.yml:252-255	The `go get` and `go mod edit` commands in the `build-dashboard-image` job use the `GATEWAY_BRANCH` environment variable (from `github.head_ref`) without quoting. This allows for command injection if a pull request is submitted with a specially crafted branch name containing shell metacharacters (e.g., `feature/fix-$(whoami)`). An attacker could execute arbitrary commands on the runner, potentially exposing secrets like `ORG_GH_TOKEN`. 💡 Suggestion Always quote variables that contain user-controllable content when used in shell commands to prevent shell expansion and command injection. 🔧 Suggested Fix go get "github.com/TykTechnologies/tyk@$GATEWAY_BRANCH" # Update replace directive if present go mod edit -replace &#34;github.com/TykTechnologies/tyk=github.com/TykTechnologies/tyk@$GATEWAY_BRANCH&#34;</code></pre>
🔴 Critical	.github/workflows/release.yml:104	The `git ls-remote` command in the `check_branch` step uses the `BRANCH` variable (derived from `github.head_ref`) without quoting. This allows for command injection if a pull request is submitted with a specially crafted branch name containing shell metacharacters. An attacker could execute arbitrary commands on the runner. 💡 Suggestion Always quote variables that contain user-controllable content when used in shell commands to prevent shell expansion. 🔧 Suggested Fix if git ls-remote --heads https://$GITHUB_TOKEN@github.com/TykTechnologies/tyk-analytics.git "refs/heads/$BRANCH" | grep -q .; then
🟠 Error	.github/workflows/release.yml:310	The `docker run` command uses the `--privileged` flag, which gives the container root capabilities on the host machine. This is a significant security risk, especially since a secret (`ORG_GH_TOKEN`) is passed to the container. If the build process within the container is compromised, an attacker could escape the container, compromise the runner, and steal secrets. 💡 Suggestion Remove the `--privileged` flag. If specific capabilities are required for the build, grant them explicitly with `--cap-add`. The `docker/setup-qemu-action` should handle requirements for multi-platform builds without needing privileged containers.

Architecture Issues (2)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:304-512	The workflow contains several long and complex inline shell scripts, particularly in the `resolve-dashboard-image` job. Embedding complex logic directly in the YAML makes it difficult to read, test, and maintain, especially for the multi-stage decision logic in the `resolve` step. 💡 Suggestion Extract the shell script logic from steps like `check_changes`, `check_branch`, `check_ecr`, and `resolve` into separate, executable script files within the repository (e.g., in a `.github/scripts/` directory). The workflow steps can then invoke these scripts. This will make the workflow YAML significantly cleaner, and the logic becomes more modular, reusable, and easier to test independently.
🟡 Warning	.github/workflows/release.yml:514	The logic for detecting the machine architecture is duplicated within the `build-dashboard-image` job. The step "Build dashboard packages for current architecture" determines `GOARCH`, and the later step "Detect platform for Docker build" determines `PLATFORM` using the exact same `case` statement on `uname -m`. 💡 Suggestion Consolidate the architecture detection into a single setup step at the beginning of the `build-dashboard-image` job. This step can determine the architecture and set both `GOARCH` and `PLATFORM` variables as outputs. Subsequent steps can then consume these outputs, removing the duplication and adhering to the Don't Repeat Yourself (DRY) principle.

✅ Performance Check Passed

No performance issues found – changes LGTM.

Quality Issues (4)

Severity	Location	Issue
🟠 Error	.github/workflows/release.yml:552	The `GATEWAY_BRANCH` environment variable is set to `github.head_ref`, which resolves to the source branch name in a pull request. Using a mutable branch name for a dependency can lead to non-reproducible builds, as the branch can be updated while the workflow is running. This could result in building the dashboard against a different gateway commit than the one that triggered the workflow. The pull request description also states the intent is to use the 'PR commit SHA', which this implementation does not do. 💡 Suggestion To ensure builds are deterministic and reproducible, use the immutable commit SHA of the pull request's head. Modify the environment variable to use `github.event.pull_request.head.sha` and rename it to reflect that it's a commit, not a branch (e.g., `GATEWAY_COMMIT`). Then, update the script to use this new variable.
🟢 Info	.github/workflows/release.yml:598-668	The shell script logic to detect the runner's architecture (`x86_64` or `aarch64`) and determine the corresponding platform string is duplicated in two separate steps: 'Build dashboard packages for current architecture' (starts line 598) and 'Detect platform for Docker build' (starts line 653). 💡 Suggestion To adhere to the DRY (Don't Repeat Yourself) principle, consolidate this logic into a single setup step at the beginning of the `build-dashboard-image` job. This step can export the `GOARCH` and Docker `PLATFORM` values as job outputs, which can then be consumed by the subsequent build steps, improving maintainability.
🟢 Info	.github/workflows/release.yml:479	The workflow logic contains a hardcoded check against the `master` branch name to determine the build strategy. If the repository's default branch is ever renamed (e.g., to `main`), this check will become outdated and require a manual update. 💡 Suggestion To make the workflow more resilient to future changes, consider comparing against the repository's default branch dynamically using the `github.repository.default_branch` context variable. For example: `if [ "${{ github.base_ref }}" != "${{ github.repository.default_branch }}" ]; then`.
🟡 Warning	.github/workflows/release.yml:327	The command to detect changed files (`git diff ... 2>/dev/null || echo ""`) suppresses all errors from `git diff` and forces the step to succeed with an empty output. This can mask underlying issues, such as a failure to fetch the base branch, causing the workflow to incorrectly determine that no relevant files have changed. This could lead to a required dashboard build being silently skipped. 💡 Suggestion Remove the error suppression (`2>/dev/null || echo ""`) to allow the step to fail fast if `git diff` encounters a legitimate error. This will make the workflow more robust and prevent silent failures.

✅ Dependency Check Passed

No dependency issues found – changes LGTM.

✅ Connectivity Check Passed

No connectivity issues found – changes LGTM.

---

Powered by Visor from Probelabs

Last updated: 2025-11-17T12:19:50.856Z | Triggered by: synchronize | Commit: 64eff4c

💡 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