Run the e2e suite against the gateway release the app targets - #104
Merged
Conversation
mfaferek93
reviewed
Sep 7, 2026
mfaferek93
reviewed
Sep 7, 2026
bburda
force-pushed
the
fix/e2e-gateway-070
branch
from
September 8, 2026 17:47
d1c0980 to
d5eb71f
Compare
Contributor
Author
|
A correction to what this PR said it was fixing. It claimed 0.7.0 tightened the script request bodies and that the older gateway accepts either shape. That is wrong: both checks are byte-identical in 0.6.0 and 0.7.0, and probing both images with the same malformed requests returns the same 400s. What 0.7.0 changed is the OpenAPI description, which matters for the generated client, so the real reason to move the pin is that package.json takes that client at ^0.7.0. I have corrected the PR description and the issue. |
The Playwright stack pinned a July build of the gateway, which reports 0.6.0, while package.json takes the generated client at ^0.7.0. The suite was running against an older schema than the app is built on. Both stacks now pin gateway 0.7.0. The pin stays a digest rather than a tag, because tags on this registry are mutable and a re-run of the publishing workflow on the same commit moves one. It is the multi-arch manifest list for the release, so an arm64 host gets a native image instead of running the gateway under emulation. The rosbag stack defaulted to the mutable :latest tag, because the recording-id contract its specs assert on was newer than any published release. It ships in 0.7.0, so that default becomes the same digest, still overridable so a locally built gateway can be dropped in ahead of a release.
The trap never ran. Compose substitutes $FM, $SEED and $GW out of the command string before the container sees it, so the container installed a trap that runs `kill` with no operands, and every run logged three "variable is not set" warnings saying so. The children were left to the container teardown, which is the fault manager killed mid-write that the trap exists to avoid. Doubling the dollars keeps them for bash. The volume comment claimed a reused volume makes the suite see three recordings instead of two, as if that were a failure. The specs assert against the count they read back from the gateway, so three would pass; a clean volume is what keeps a local run comparable with CI, not what makes it correct.
The e2e job started only the scripts stack. The three rosbag specs need a fault manager, which that stack does not run, so they skipped themselves on every run. A skip is green, so the job reported success whether or not they ever executed. The job now starts the rosbag stack too, on its own port, and waits for the fixture before running the suite. The wait judges the same app the specs judge: they take the first app whose fault list carries the code and never look further, so scanning on to a healthier one would let the wait pass while they skip. Anything that is not a plain count means the fixture is not ready rather than an app to step over, because the specs parse those same bodies and throw on a bad one. The deadline is checked again before success is declared, since the two requests before it can take five seconds each. The rosbag stack is torn down with -v because its volume holds faults.db as well as the bags, so a reused one starts with the fault already confirmed and seeds a different number of recordings than a clean run. CONTRIBUTING.md and README.md described a one-stack local run, which left the rosbag specs skipping on a developer machine even after CI stopped letting them, and offered port 8081 as the workaround for a busy 8080 - the rosbag stack's own default.
bburda
force-pushed
the
fix/e2e-gateway-070
branch
from
September 9, 2026 12:02
d7bc878 to
e35f192
Compare
mfaferek93
approved these changes
Sep 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request
Summary
The Playwright stack pinned a gateway image built in July, which reports version 0.6.0.
package.jsontakes the generated client at^0.7.0, so the suite was running against an older schema than the one the app is built on. The pin moves to gateway 0.7.0.It stays a digest rather than a tag, because tags on this registry are mutable and a re-run of the publishing workflow on the same commit moves one.
The digest is the multi-arch manifest list for 0.7.0, so an arm64 host gets a native image. That needed a detour: the release had no multi-arch image, because the gateway's multi-arch workflow only triggers on
v*tags while release tags there are bare semver, so it has not run on a release since 0.1.0. The manifest list for 0.7.0 was produced by a manual dispatch on the tag, and a fix for the trigger is open on the gateway side.docker-compose.rosbag.ymldefaulted its gateway image to the mutable:latesttag, because the recording-id contract its specs assert on was newer than any published release. It ships in 0.7.0, so that default is now the same digest. It stays overridable, so a locally built gateway can be dropped in ahead of a release.The
e2ejob now runs that second stack. It never did, so the three rosbag specs skipped themselves on every run, and a skip is green. The job starts the rosbag stack on its own port and waits for the seeded fixture first, failing there if it never appears, so the specs cannot go back to skipping unnoticed.Issue
Type
Testing
The digest was resolved from the registry and the image was started and asked directly:
GET /api/v1/reports0.7.0, on both architectures of the manifest list.The suite runs in this PR's own
e2ejob. With the rosbag stack wired in, it reports24 passedand no skips, where before it was21 passed, 3 skipped. The fixture wait logs what it found:e2e_rosbag_seeder holds 2 recordings for E2E_FLAPPING_SENSOR. That is the first time the rosbag specs have actually executed in CI.One correction to the original description of this change. It said 0.7.0 tightened the script request bodies and that the older gateway accepts either shape. That is wrong. Both checks are byte-identical in 0.6.0 and 0.7.0, and probing both images with the same malformed requests returns the same 400s. What 0.7.0 changed is the OpenAPI description, which matters for the generated client, not for what the gateway accepts at runtime. The reason to move the pin is the client version, not a runtime contract change.
Checklist
npm run lint)npm run build)