fix: extract container name when docker call is wrapped in shell logic#16
Merged
ItzNotABug merged 2 commits intoJun 22, 2026
Merged
Conversation
extractContainerName only matched docker exec / docker compose exec at the start of the command (after skipping leading KEY=value tokens), so a command that wraps the docker call in shell logic — variable assignments, conditionals, && chains — failed to resolve a container name. This skipped JUnit extraction and, in turn, per-test failure detection, even though isDockerCommand() and extractJUnitPath() both already match the pattern anywhere in the command. Scan for the docker exec / docker compose exec / docker-compose exec segment anywhere in the token stream, matching the substring-based detection used elsewhere. The leading KEY=value skip is now subsumed by the scan. Adds regression tests for wrapped-script and &&-chain commands and rebuilds dist.
bun's minifier mangles identifiers differently per platform; the prior dist was built on macOS arm64, so CI's linux x64 rebuild produced a different bundle and the dist-drift check failed. Rebuild under oven/bun:latest (linux/amd64) so the committed bundle matches CI.
ItzNotABug
approved these changes
Jun 22, 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
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.
Problem
extractContainerName()only recognized the docker call when it appeared at the start of the command (after skipping leadingKEY=valuetokens). When a workflow wraps the docker call in shell logic — variable assignments, conditionals,&&chains — the parser hit a non-docker token first and returnednull:This produced:
JUnit extraction was skipped, so per-test failure detection (and therefore targeted retry) silently degraded to retrying the whole command — even though the command is a valid docker command.
Root cause: internal inconsistency
The action already detects the docker pattern anywhere in two places, but
extractContainerNamewas the odd one out:isDockerCommand/isDockerComposecommand.includes('docker compose exec')extractJUnitPathcommand.match(/--log-junit\s+(\S+)/)extractContainerNameSo
isDockerCommandreturns true (action takes the docker path) butextractContainerNamereturns null — the extraction is skipped.Fix
Scan the token stream for the
docker exec/docker compose exec/docker-compose execsegment anywhere, then keep the existing flag-skipping logic from there. This matches the substring-based detection used elsewhere, and the leadingKEY=valueskip is now subsumed by the scan (existing env-var tests still pass unchanged).Tests
extractContainerNametests pass unchanged (including the leading-env-var cases).&&-chained command.bun test tests/unit/→ 119 pass / 0 fail.bun run check(prettier + tsc) clean.dist/index.jsrebuilt viabun run build.No runtime/dependency changes; only the parser logic and the rebuilt bundle.