The GitLab recipe now runs on a CI runner, and the merge request carries only translations

[pavel-te]

The recipe could not translate anything

A CI runner checks out a detached HEAD. There git branch --show-current succeeds and prints an empty string, so the || fallbacks in get_current_branch were never reached and the empty file tag was rejected by validate_args — before a single request to the API.

Reproduced against a mock API, on a detached HEAD, with the recipe's exact command:

recipe as printed (no --file-tag-name):   EXIT=1   on disk: en.json
same, with --file-tag-name:               EXIT=0   on disk: de.json en.json fr.json

So every push to the default branch gave a red job, uploaded nothing and opened no merge request. Four of the five copies of this recipe carried the defect; only the one the product prints passed --file-tag-name and worked.

An empty answer is now treated as no answer: the runner's own branch variable is consulted (GitLab, GitHub, Bitbucket, Jenkins, CircleCI), then main. That fixes the printed recipe, the standalone snippet, and every other CI whose checkout is detached.

The merge request carried more than translations

The recipe curled the CLI into the project root and then ran git add -A:

=== what landed in the merge request ===
.ptc-config.yml
locales/de.json
ptc-cli.sh          <- the CLI the recipe had just downloaded

And because that download is always a new file, git diff --cached --quiet never short-circuited — every run force-updated the merge request even when no translation had changed.

The CLI now downloads outside the checkout, and --written-manifest FILE records what the run wrote: NUL-separated, repository-root-relative, for git add --pathspec-from-file=FILE --pathspec-file-nul. git reads it directly, so the recipe needs no arrays or word splitting — its shell is busybox sh, since alpine has no bash until before_script installs it.

Verified in alpine:3.22 (git 2.49.1): a path with a glob metacharacter stages the wrong file unless written as :(literal), and an ignored path makes git exit 1 while still staging the rest — hence || true, without which GitLab aborts the job.

The unpack filter dropped documented types

in the archive:  a.json  b.php  c.properties  dir.po/(a directory)
the filter gave: a.json  dir.po

.php is documented as an additional_translation_files companion, .properties as a source pattern — neither reached disk. And -o binds looser than the implicit -a, so -type f applied only to the first -name: a directory named *.po matched and was moved wholesale.

[skip ci] left the commit message

GitLab honours it by creating no pipeline at all, which silenced the translation merge request's own pipeline — the translations could not be tested before merge, and with "Pipelines must succeed" enabled the MR could never be merged. A squash carried it into the default branch and silenced the whole project. The guard now lives in rules:, which GitLab evaluates without suppressing anything.

Tests

tests/test-ci-recipe.sh executes the printed recipe against a mock PTC API on localhost — no docker, ~2 s — with only curl and git push shimmed, and asserts what the merge request would contain. Eight cases: translation on a detached HEAD, only-translations-committed, the CLI neither committed nor left behind, no push when nothing changed, and the push shape.

tests/test-git-context.sh now pins the detached-HEAD behaviour it previously documented as a known defect and deferred. tests/test-init.sh gained a check that the README's copy of the recipe is the one the CLI prints — these copies have drifted three ways before.

All nine suites green.