Skip to content

Docker E2E job in testing.yaml fails on feature-branch pushes: cargo run lacks the e2e-tools package flag #2179

Description

@da2ce7

Goal

Restore the Docker E2E job in .github/workflows/testing.yaml to a state where its four E2E runner steps actually execute, by naming the package that owns the binaries on each cargo run invocation exactly as .github/workflows/container.yaml already does, so that feature-branch pushes and pull requests targeting branches other than develop and main regain the E2E coverage the job exists to provide.

Background

The docker-e2e job in testing.yaml (lines 124-197) exists to give E2E coverage to the events container.yaml does not cover: its if: guard (lines 133-139) skips it on pull requests targeting develop or main and on pushes to develop, main, and releases/*, because container.yaml runs the same E2E tests for exactly those events (the job comment cites #1854). What remains is precisely the feature-branch case.

That job cannot reach its tests. Its four runner steps (lines 185, 189, 193, 197) invoke cargo run --bin e2e_tests_runner … and cargo run --bin qbittorrent_e2e_runner … without naming the package that owns the binaries. Both live in torrust-tracker-e2e-tools (packages/e2e-tools/src/bin/), and the workspace root is itself a package ([package] name = "torrust-tracker", default-run = "torrust-tracker", no default-members), so from the root cargo run --bin <name> resolves only against the root package and fails before any image is exercised: error: no bin target named 'e2e_tests_runner' in default-run packages, exit 101. The same four invocations in container.yaml (lines 117, 123, 127, 131) carry -p torrust-tracker-e2e-tools, which is why that workflow is green.

Origin: commit c1b6c54 (2026-06-03) added only the guard. Commit c47173f (2026-06-04) moved the runner sources into packages/e2e-tools as pure renames and touched neither workflow, breaking both. Commit 2d1ce24 (2026-06-04) repaired container.yaml alone, adding -p torrust-tracker-e2e-tools and wrapping the long step in a >- block scalar; testing.yaml was missed. The guard contributed the silence: develop and pull requests to develop never execute the job, so upstream CI has stayed green while the job has failed on every feature-branch push since June 2026. It has surfaced on the dependency-update pull requests #2055 and #2106, whose branch pushes trigger it, and on a fork push of the merge-tool-symlink-exceptions-spec branch on 2026-09-08.

One detail is load-bearing: .yamllint-ci.yml sets line-length: max: 200. Line 185 is 184 characters; the flag plus its separating space adds 26, to 210. The other three land at 179, 177, and 182. The first step must therefore be wrapped in a >- block scalar, the form container.yaml already uses for the same step and the same reason.

Scope

In scope: add -p torrust-tracker-e2e-tools to the four cargo run invocations, keeping every other argument byte-for-byte; wrap the run-tracker-e2e-tests command in a >- block scalar; extend the job comment with one sentence on why the flag is required; verify by pushing the branch to a fork or another in-repo feature branch, where the guard admits the job, and record the passing run URL.

Out of scope: changing when the job runs (the guard and triggers stay as they are); deduplicating it against container.yaml; the runners, packages/e2e-tools, or the image build; container.yaml itself; the stale src/bin/ inventory in AGENTS.md (same drift from c47173f, worth its own issue); any general CI policy about jobs that can only fail where nobody looks.

Acceptance criteria

  • AC1: The four cargo run invocations in the docker-e2e job each carry -p torrust-tracker-e2e-tools, every other argument unchanged.
  • AC2: On a push to a feature branch, the Docker E2E job of testing.yaml runs, its four runner steps reach the E2E runners rather than failing on target resolution, and the job completes successfully; evidence is the run URL.
  • AC3: container.yaml is unchanged.
  • AC4: The docker-e2e job comment records why the package flag is required.

Verification

A pull request to develop cannot prove the fix, because the guard skips the job there. Verification is a feature-branch push where the job runs (M1), plus confirming a pull request to develop still skips it, i.e. behaviour on develop is unchanged (M2). linter all covers the yamllint constraint.

Specification

Folder-style specification drafted at docs/issues/drafts/docker-e2e-job-package-flag/ISSUE.md (spec-first per the create-issue skill); it moves to docs/issues/open/ under this issue's number in a spec-only PR, followed by the fix.

Related: #1854 (why the job and its guard exist; closed), #1840 (the workflow-performance EPIC that work belonged to; not a parent of this issue).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    BugIncorrect Behavior

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions