[TT-16950] fix: dashboard resolver matches release branches (release-5.12.1)

[buger]

Summary

• For PRs targeting release branches, the dashboard resolver now checks if the base branch exists in tyk-analytics and uses it directly via ECR image
• Previously always fell back to gromit-default (master), causing test failures due to dashboard/gateway version mismatch
• Adds ORG_GH_TOKEN to the resolve step's env block for authenticated git ls-remote against private tyk-analytics repo

Same fix as #8043 (master) and #8044 (release-5.12).

Test plan

• CI passes on this PR
• Verify that PRs targeting release-5.12.1 correctly resolve dashboard image from tyk-analytics release-5.12.1 branch

Generated with Claude Code

[github-actions]

API Changes

no api changes detected

[probelabs]

This PR fixes a bug in the CI workflow where pull requests targeting release branches (e.g., release-5.12.1) failed during integration testing. Previously, the workflow would always use the master version of the Tyk Dashboard image, leading to version mismatches with the Gateway.

The change updates the resolve-dashboard-image step in the .github/workflows/release.yml file. It now checks if a corresponding branch exists in the private tyk-analytics repository. If a matching release branch is found, it uses the corresponding Docker image. If not, it falls back to the previous default behavior. This is achieved by using an authenticated git ls-remote command, which requires the new ORG_GH_TOKEN secret.

Files Changed Analysis

• .github/workflows/release.yml: Modified to enhance the logic for resolving the Dashboard image. The script now attempts to find a matching release branch in the tyk-analytics repository before defaulting to the master image, ensuring version compatibility for tests on release branches.

Architecture & Impact Assessment

• What this PR accomplishes: It ensures that CI integration tests for release branches use a version-compatible Tyk Dashboard image, preventing test failures caused by version skew between the Gateway and Dashboard.
• Key technical changes introduced:
  • The workflow script now performs a git ls-remote check against the tyk-analytics repository.
  • It requires the ORG_GH_TOKEN secret to authenticate against the private repository.
  • Logic is added to use a Docker image tagged with the release branch name if the branch exists.
• Affected system components: This change primarily affects the CI/CD pipeline for integration testing. It modifies the environment setup for tests running against release branches.

graph TD
    A[Start: PR on release branch] --> B{Resolve Dashboard Image};
    B --> C{Is base branch a release branch?};
    C -- Yes --> D{Does matching branch exist in tyk-analytics?};
    C -- No --> G[Proceed with master branch logic];
    D -- Yes --> E[Use image from matching release branch];
    D -- No --> F[Fallback to default master image];
    E --> H[Run Integration Tests];
    F --> H;
    G --> H;

Loading

Scope Discovery & Context Expansion

• The change is confined to the CI workflow configuration but has cross-repository implications. It establishes a dependency where the CI for the tyk repository relies on the branching strategy of the tyk-analytics repository for successful test runs on release branches.
• Subsequent steps in the release.yml workflow will consume the output of the resolve-dashboard-image step to pull and run the correct Docker container for the integration tests.

Metadata

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

---

Powered by Visor from Probelabs

Last updated: 2026-04-16T15:24:44.153Z | Triggered by: pr_opened | Commit: 938ea9b

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

[probelabs]

Security Issues (2)

Severity	Location	Issue
🟠 Error	.github/workflows/release.yml:515-525	The `git ls-remote` command uses the `$BASE_REF` variable, derived from `github.base_ref`, directly in a shell command. While `github.base_ref` refers to the target branch of the pull request and is generally safe, it is not guaranteed to be sanitized. A malicious actor with permissions to create branches in the repository could create a branch with a name containing shell metacharacters (e.g., `release-1.0; malicious_command`). This could lead to command injection, allowing arbitrary code execution on the GitHub Actions runner and potential exfiltration of secrets like `ORG_GH_TOKEN`. 💡 Suggestion Validate the content of the `$BASE_REF` variable to ensure it only contains characters that are valid for a git branch name before using it in the shell command. This provides a defense-in-depth measure against command injection.
🟡 Warning	.github/workflows/release.yml:515	The `ORG_GH_TOKEN` secret is embedded directly into the HTTPS URL for the `git ls-remote` command. This can expose the token in the runner's process list, which could be inspected by other processes on the same runner or through a compromised build step. While GitHub Actions runners provide isolation, this pattern is less secure than using credential helpers. 💡 Suggestion Use a git credential helper or `git config` to provide authentication credentials. This avoids placing the raw token on the command line. Also, ensure the `ORG_GH_TOKEN` is a fine-grained personal access token with the minimum required permissions (read-only access to the `TykTechnologies/tyk-analytics` repository).

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:515	The `git ls-remote` command redirects both stdout and stderr to `/dev/null` (`> /dev/null 2>&1`). This suppresses all output, including critical error messages. If the command fails for reasons other than the branch not being found (e.g., an invalid `ORG_GH_TOKEN`, network issues, or repository permission changes), the script will silently fall back to the default strategy without logging the underlying error. This significantly complicates debugging CI failures. 💡 Suggestion Only redirect stdout to `/dev/null` and allow stderr to be printed to the logs. The `git ls-remote` command is silent on success, so this change will only add output to the logs when an error occurs, providing crucial information for debugging. 🔧 Suggested Fix if git ls-remote --exit-code --heads "https://x-access-token:${ORG_GH_TOKEN}@github.com/TykTechnologies/tyk-analytics.git" "refs/heads/$BASE_REF" > /dev/null; then

✅ Performance Check Passed

No performance issues found – changes LGTM.

---

Powered by Visor from Probelabs

Last updated: 2026-04-16T15:24:45.365Z | Triggered by: pr_opened | Commit: 938ea9b

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

[github-actions]

🚨 Jira Linter Failed

Commit: 938ea9b
Failed at: 2026-04-21 10:09:42 UTC

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

🔍 Click to view error details

failed to get Jira issue: failed to fetch Jira issue TT-16950: Issue does not exist or you do not have permission to see it.: request failed. Please analyze the request body for more details. Status code: 404

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.