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

[buger]

Summary

• For release branch PRs, the dashboard resolver now checks if the base branch exists in tyk-analytics and uses it directly
• Previously any non-master BASE_REF immediately got strategy=gromit-default, which mapped to tyk-analytics:master -- causing test failures due to dashboard/test version mismatch
• Adds ORG_GH_TOKEN to the resolver step env for git ls-remote authentication

Test plan

• Verify PR targeting release-5.12 resolves to tyk-analytics:release-5.12 via release-branch-match strategy
• Verify PR targeting a non-existent release branch falls back to gromit-default

Generated with Claude Code

[github-actions]

🚨 Jira Linter Failed

Commit: 5f1063c
Failed at: 2026-04-16 15:16:17 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 'hotfix/fix-dashboard-resolver-5.12' 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.

[probelabs]

This PR fixes a bug in the release.yml GitHub Actions workflow that caused incorrect test failures for pull requests targeting release branches.

Files Changed Analysis

• File: .github/workflows/release.yml
• Changes: 17 additions, 7 deletions.
• Summary: The changes introduce new logic within the "Dashboard Image Resolution" step. A simple check for the master branch is replaced with a more robust mechanism that inspects the tyk-analytics repository for a matching release branch.

Architecture & Impact Assessment

What this PR accomplishes:
This PR ensures that when a pull request targets a release branch (e.g., release-5.12), the CI pipeline uses the corresponding version of the Tyk Dashboard (tyk-analytics:release-5.12) for integration tests. Previously, it would default to tyk-analytics:master, leading to version mismatches and test failures.

Key technical changes introduced:

• The workflow now uses git ls-remote to check if the PR's base branch exists in the TykTechnologies/tyk-analytics repository.
• The ORG_GH_TOKEN secret is now passed to the step to authenticate the git command against the private tyk-analytics repository.
• A new resolution strategy, release-branch-match, is introduced for when a corresponding release branch is found.

Affected system components:

• The primary impact is on the CI/CD pipeline for this repository, specifically the integration tests that depend on the Tyk Dashboard.
• It improves the reliability of testing for release branches, ensuring that gateway changes are validated against the correct dashboard version.

Workflow Logic:

graph TD
    A[Start: Resolve Dashboard Image] --> B{"PR base branch is 'master'?"};
    B -- Yes --> C[Use existing master branch logic];
    B -- No --> D{Does matching branch exist in tyk-analytics?};
    D -- Yes --> E[Use matching branch image, e.g., tyk-analytics:release-5.12];
    D -- No --> F["Fallback to default (master) image"];

Loading

Scope Discovery & Context Expansion

This change is confined to the CI configuration but has implications for the multi-repository release process involving tyk and tyk-analytics. It codifies the assumption that release branches are maintained in parallel across both repositories. The dashboard_image output from this step is consumed by subsequent jobs in the workflow that run integration tests, which will now receive the correctly versioned dashboard image. The introduction of ORG_GH_TOKEN highlights the dependency and need for authentication between these two core component repositories during the CI process.

Metadata

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

---

Powered by Visor from Probelabs

Last updated: 2026-04-16T15:17:45.568Z | Triggered by: pr_opened | Commit: 5f1063c

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

[probelabs]

\n\n

Architecture Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:518-529	The script assumes any failure of the `git ls-remote` command means the branch does not exist. The command can also fail due to other reasons like invalid credentials or network issues. In these failure scenarios, the log message at line 526 ('base branch ... not found') would be misleading, making it harder to diagnose problems with secrets or connectivity. 💡 Suggestion Distinguish between the 'branch not found' exit code (2) and other error codes from `git ls-remote`. Log a more specific warning for unexpected errors to aid troubleshooting. 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 2>&1; then echo "📋 Strategy: Use release branch '$BASE_REF' from tyk-analytics" echo " → Base branch exists in tyk-analytics, using it directly" echo "dashboard_image=${REGISTRY}/tyk-analytics:${BASE_REF}" >> $GITHUB_OUTPUT echo "needs_build=false" >> $GITHUB_OUTPUT echo "dashboard_branch=$BASE_REF" >> $GITHUB_OUTPUT echo "strategy=release-branch-match" >> $GITHUB_OUTPUT else exit_code=$? if [ $exit_code -eq 2 ]; then echo "ℹ️ Strategy: Use gromit default (base branch '$BASE_REF' not found in tyk-analytics)" else echo "::warning::'git ls-remote' failed with exit code $exit_code. This could be an authentication or network issue. Falling back to gromit default." fi echo " → Falling back to gromit default" echo "dashboard_image=" >> $GITHUB_OUTPUT echo "needs_build=false" >> $GITHUB_OUTPUT echo "dashboard_branch=" >> $GITHUB_OUTPUT echo "strategy=gromit-default" >> $GITHUB_OUTPUT fi

✅ Performance Check Passed

No performance issues found – changes LGTM.

Quality Issues (1)

Severity	Location	Issue
🟡 Warning	.github/workflows/release.yml:516	The `git ls-remote` command redirects both stdout and stderr to `/dev/null`. This suppresses potentially useful error messages, such as those related to authentication failures. If the `ORG_GH_TOKEN` is invalid or lacks permissions, the command will fail silently, and the script will incorrectly report that the release branch was not found in `tyk-analytics`, making it difficult to diagnose the root cause of a CI failure. 💡 Suggestion To improve debuggability, allow stderr from the `git ls-remote` command to be printed to the action log by only redirecting stdout. Change `> /dev/null 2>&1` to `> /dev/null`.

---

Powered by Visor from Probelabs

Last updated: 2026-04-16T15:17:39.909Z | Triggered by: pr_opened | Commit: 5f1063c

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

[github-actions]

API Changes

no api changes detected