TT-17874: timeout docker-compose log collection in reporting action

[konrad-sol]

What

Bounds the log-collection step in the shared tests/reporting action with a timeout.

The "Docker logs for all components" step runs docker compose … logs, which can hang if a container is unresponsive — running the calling test job to its full timeout (e.g. 45 min) just to collect diagnostics. This wraps it in timeout 300 so it's capped at 5 min, emits a ::warning:: on miss, and stays best-effort (a slow/failed log dump never fails the job).

timeout-minutes isn't supported on composite-action steps, so the command itself is bounded. The action is shared, so this covers both API and UI test reporting.

Part of TT-17874 (release-pipeline speed-up). Companion PRs: gromit templates (TykTechnologies/gromit#521), tyk-analytics test fixes (TykTechnologies/tyk-analytics#6047).

TT-17874

🤖 Generated with Claude Code

[probelabs]

This PR introduces a timeout to the log collection step in a shared GitHub Action to prevent CI jobs from hanging.

Files Changed Analysis

The single modified file is .github/actions/tests/reporting/action.yaml. The change replaces a direct docker compose ... logs command with a shell script that wraps the command in timeout 300. This bounds the log collection to 5 minutes. If the command exceeds this time, it is terminated, and a non-fatal warning is issued to the workflow, ensuring the job can proceed. This makes the log collection a best-effort, non-blocking step.

Architecture & Impact Assessment

Accomplishment: This PR prevents a potential CI pipeline failure where an unresponsive container could cause the docker compose logs command to hang indefinitely, forcing the entire job to run until its maximum timeout (e.g., 45 minutes). By adding a 5-minute timeout, it makes the pipeline more resilient and faster to fail.

Key Technical Changes:

• The docker compose logs command is now executed via the timeout 300 command.
• A failure in the log collection (due to timeout) is now handled gracefully (|| echo "::warning::...") and does not fail the CI step.

Affected System Components:

• The primary component affected is the reusable GitHub composite action defined in .github/actions/tests/reporting/action.yaml.
• As stated in the PR description, this action is shared across API and UI test pipelines, so any workflow using it will inherit this change.

graph TD
    subgraph "CI Workflow (API/UI Tests)"
        A[Test Job] --> B["uses: ./.github/actions/tests/reporting"];
    end

    subgraph "reporting action"
        B --> C["Step: 'Docker logs for all components'"];
    end

    subgraph "PR Change"
        C -- wraps command with --> D["timeout 300"];
    end

    style D fill:#c9f,stroke:#333,stroke-width:2px

Loading

Scope Discovery & Context Expansion

The change is localized to a single composite action, but its impact is broader due to the action's reusable nature. According to the PR description, this action is a shared dependency for both API and UI test reporting. While a search within this repository did not reveal the specific workflows that consume this action, the context provided by the author implies it is a foundational component for test diagnostics across multiple test suites, potentially in other repositories or dynamically triggered workflows. The change improves the reliability of any pipeline that relies on this reporting action.

Metadata

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

---

Powered by Visor from Probelabs

Last updated: 2026-08-05T14:46:42.777Z | Triggered by: pr_opened | Commit: 912ee06

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

[probelabs]

Security Issues (1)

Severity	Location	Issue
🟡 Warning	.github/actions/tests/reporting/action.yaml:52-54	The redirection of stderr (`2>&1`) to the log file, which is subsequently printed to the GitHub Actions logs, increases the risk of exposing sensitive information. While the previous implementation already captured stdout, stderr may contain more verbose error details, stack traces, or configuration issues that could inadvertently include secrets, internal paths, or other sensitive data from the test environment. 💡 Suggestion Before printing the combined logs to the GitHub Actions output, consider scrubbing them for potential secrets (e.g., API keys, passwords, connection strings). Alternatively, validate that no service running within the Docker Compose setup ever prints sensitive information to stderr on failure.

✅ Architecture Check Passed

No architecture issues found – changes LGTM.

✅ Performance Check Passed

No performance issues found – changes LGTM.

---

Powered by Visor from Probelabs

Last updated: 2026-08-05T14:46:15.594Z | Triggered by: pr_opened | Commit: 912ee06

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

[konrad-sol]

Superseded — moved the log-collection timeout to the workflow level in the gromit template (TykTechnologies/gromit#521): the "Generate test reports and collect logs" step now has timeout-minutes: 8 + continue-on-error, so the reporting composite action no longer needs its own timeout wrapper. Closing.