Skip to content

fix: extract container name when docker call is wrapped in shell logic#16

Merged
ItzNotABug merged 2 commits into
ItzNotABug:mainfrom
ChiragAgg5k:fix/extract-container-name-anywhere
Jun 22, 2026
Merged

fix: extract container name when docker call is wrapped in shell logic#16
ItzNotABug merged 2 commits into
ItzNotABug:mainfrom
ChiragAgg5k:fix/extract-container-name-anywhere

Conversation

@ChiragAgg5k

Copy link
Copy Markdown
Contributor

Problem

extractContainerName() only recognized the docker call when it appeared at the start of the command (after skipping leading KEY=value tokens). When a workflow wraps the docker call in shell logic — variable assignments, conditionals, && chains — the parser hit a non-docker token first and returned null:

command: |
  SERVICE_PATH="/usr/src/code/tests/e2e/Services/Account"
  FLAG=""
  if [ "${{ matrix.functional }}" = "true" ]; then FLAG="--functional"; fi
  docker compose exec -T -e _APP_VAR="x" appwrite vendor/bin/paratest "$SERVICE_PATH" --log-junit ...

This produced:

Warning: Could not extract container name from command, JUnit XML extraction skipped
Warning: Tests failed but no specific failures in JUnit XML

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 extractContainerName was the odd one out:

Function Detection Wrapped command
isDockerCommand / isDockerCompose command.includes('docker compose exec')
extractJUnitPath command.match(/--log-junit\s+(\S+)/)
extractContainerName positional, must be at start

So isDockerCommand returns true (action takes the docker path) but extractContainerName returns null — the extraction is skipped.

Fix

Scan the token stream for the docker exec / docker compose exec / docker-compose exec segment anywhere, then keep the existing flag-skipping logic from there. This matches the substring-based detection used elsewhere, and the leading KEY=value skip is now subsumed by the scan (existing env-var tests still pass unchanged).

Tests

  • All existing extractContainerName tests pass unchanged (including the leading-env-var cases).
  • Added regression tests for a shell-wrapped command and an &&-chained command.
  • bun test tests/unit/ → 119 pass / 0 fail. bun run check (prettier + tsc) clean.
  • dist/index.js rebuilt via bun run build.

No runtime/dependency changes; only the parser logic and the rebuilt bundle.

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
ItzNotABug merged commit 6054750 into ItzNotABug:main Jun 22, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants