fix: add fallback to master for test-controller action

[probelabs]

Problem / Task

When fetching test configuration from TUI, if the branch is not explicitly defined, it returns a 404 and the pipeline fails. We need to implement a client-side fallback to retry fetching the configuration using master as the base branch.

Changes

• Updated .github/actions/tests/test-controller/action.yaml to implement a fallback mechanism based on HTTP 404 status code.
• If the initial curl request for $BASE_REF returns a 404, it retries with master as the base branch.
• If the status code is >= 400, it fails the step and outputs the body.
• Handled curl output correctly to prevent appending a 404 HTML body to $GITHUB_OUTPUT.

Testing

• Verified the script logic locally.
• The fallback should now correctly fetch the configuration for master when the current branch is not found.

[probelabs]

This PR enhances the test-controller GitHub Action to be more resilient. It introduces a fallback mechanism to prevent CI failures when a test configuration for a specific branch is not found. If fetching the configuration for the current branch results in a 404 error, the action will now automatically retry the request using the master branch.

Additionally, the script's error handling has been improved. It now captures the HTTP status code and response body separately, ensuring that only valid configurations are written to the action's output and preventing server error pages from corrupting the CI process.

Files Changed Analysis

• File: .github/actions/tests/test-controller/action.yaml
• Changes: The previous single-line curl command has been replaced with a more robust shell script. This new script checks the HTTP status code of the fetch request. If a 404 is detected, it attempts a fallback to the master branch. It also ensures that if both requests fail, the action exits with an error instead of passing a failed response downstream.

Architecture & Impact Assessment

• What this PR accomplishes: It prevents CI pipeline failures for branches that do not have a dedicated test configuration by providing a default configuration from the master branch.
• Key technical changes introduced:
  • A conditional check for the HTTP 404 status code to trigger a fallback.
  • Use of curl -w "%{http_code}" to reliably capture the server's response code.
  • The response body is temporarily stored to prevent writing error pages to $GITHUB_OUTPUT.
• Affected system components: Any CI workflow that utilizes the .github/actions/tests/test-controller reusable action will be affected. This change alters the behavior for feature branches, which will now run against the master test configuration by default if a branch-specific one does not exist.

graph TD
    A[Start Action] --> B{"Fetch config for current branch ($BASE_REF)"};
    B -->|Success (HTTP 200)| C[Use branch config];
    B -->|Not Found (HTTP 404)| D{"Fallback: Fetch config for 'master' branch"};
    D -->|Success (HTTP 200)| E["Use 'master' config"];
    D -->|Failure (HTTP >= 400)| F[Fail pipeline];
    C --> G[End];
    E --> G[End];
    F --> G[End];

Loading

Scope Discovery & Context Expansion

• The change is localized to the test-controller action but has a broad impact on the repository's testing strategy, as this action is likely used by multiple CI workflows. It relies on an internal service (tui.internal.dev.tyk.technology) and establishes a convention that master holds the default or baseline test configuration.
• To fully assess the impact, one would need to find all workflow files in the .github/workflows/ directory that contain the string uses: ./.github/actions/tests/test-controller to identify every CI job that will inherit this new fallback behavior.

Metadata

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

---

Powered by Visor from Probelabs

Last updated: 2026-04-09T08:57:24.487Z | Triggered by: pr_updated | Commit: ae368f6

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

[probelabs]

Security Issues (3)

Severity	Location	Issue
🔴 Critical	.github/actions/tests/test-controller/action.yaml:40-45	The action fetches configuration from `http://tui.internal.dev.tyk.technology` over an unencrypted connection. This exposes the contents of the configuration file to network eavesdropping. If the configuration contains secrets or sensitive data, they could be compromised. 💡 Suggestion Change the protocol from `http` to `https` in the URLs to ensure the connection is encrypted. The internal server must be configured to support HTTPS.
🟠 Error	.github/actions/tests/test-controller/action.yaml:40-45	The URL path is constructed by concatenating variables like `$BASE_REF`, `$VARIATION`, and `$TEST_TYPE` without any sanitization. A malicious branch name or action input containing path traversal sequences (e.g., `../`) could allow an attacker to request arbitrary files from the `tui.internal.dev.tyk.technology` server, assuming the server is also vulnerable. 💡 Suggestion Before constructing the URL, validate each variable used as a path segment to ensure it does not contain `..` or other characters that could be used for path manipulation. Add validation checks at the beginning of the script.
🟡 Warning	.github/actions/tests/test-controller/action.yaml:51	When a `curl` request fails (HTTP status >= 400), the entire response body is printed to the GitHub Actions log via `cat response.txt`. If the server's error pages contain sensitive information such as stack traces, internal file paths, or configuration details, this information will be exposed in the logs. 💡 Suggestion Avoid printing the full response body on error. If debugging information is needed, consider using GitHub secrets to enable a verbose mode or ensure the server is configured to return generic, non-revealing error pages. Alternatively, you could truncate the output, for example: `head -c 1024 response.txt`.

Performance Issues (1)

Severity	Location	Issue
🟡 Warning	.github/actions/tests/test-controller/action.yaml:43-59	The script uses a hardcoded temporary file name (`response.txt`) to store the curl response. This is not ideal for resource management as the file is not cleaned up after the script finishes. In an ephemeral CI runner this is a minor issue, but it's a best practice to manage temporary files explicitly. 💡 Suggestion Use `mktemp` to create a temporary file with a unique name and a `trap` to ensure it is removed when the script exits, regardless of success or failure. This improves the script's robustness and resource handling. 🔧 Suggested Fix TMP_RESPONSE_FILE=$(mktemp) trap 'rm -f -- "$TMP_RESPONSE_FILE"' EXIT URL=&#34;http://tui.internal.dev.tyk.technology/v2/$VARIATION/$REPO_NAME/$BASE_REF/$TRIGGER/$TEST_TYPE.gho&#34; # Fetch the configuration and capture the HTTP status code HTTP_CODE=$(curl -s -o &#34;$TMP_RESPONSE_FILE&#34; -w &#34;%{http_code}&#34; --retry 5 --retry-delay 10 &#34;$URL&#34;) # If 404, fallback to master branch if [ &#34;$HTTP_CODE&#34; -eq 404 ]; then echo &#34;Configuration not found for base_ref &#39;$BASE_REF&#39;. Falling back to &#39;master&#39; branch.&#34; FALLBACK_URL=&#34;http://tui.internal.dev.tyk.technology/v2/$VARIATION/$REPO_NAME/master/$TRIGGER/$TEST_TYPE.gho&#34; HTTP_CODE=$(curl -s -o &#34;$TMP_RESPONSE_FILE&#34; -w &#34;%{http_code}&#34; --retry 5 --retry-delay 10 &#34;$FALLBACK_URL&#34;) fi # If still an error (&gt;= 400), fail the step and output the body if [ &#34;$HTTP_CODE&#34; -ge 400 ]; then echo &#34;Failed to fetch configuration: HTTP $HTTP_CODE&#34; cat &#34;$TMP_RESPONSE_FILE&#34; exit 1 fi # Write the successful response to GITHUB_OUTPUT cat &#34;$TMP_RESPONSE_FILE&#34; | tee -a &#34;$GITHUB_OUTPUT&#34;</code></pre>

---

Powered by Visor from Probelabs

Last updated: 2026-04-09T08:56:23.512Z | Triggered by: pr_updated | Commit: ae368f6

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