test: exercise the action on Gitea with a Rust integration test

[marcoienibot]

Add a Docker-backed integration test that runs the checked-out action through a real Gitea server and Gitea Actions runner. A tagged Rust fixture receives a fix commit, and the test verifies that release-plz opens a 0.1.1 release PR, changes the manifest and changelog, and returns outputs matching the Gitea API.

The Rust test crate exercises forge: gitea. Each run uses isolated containers, generated credentials, a dynamic localhost port, failure logs, and automatic cleanup. The GitHub test workflow now runs this test, and the README documents the local command.

Validation: Cargo fmt, Clippy with warnings denied, and actionlint passed. The Gitea release PR test also passed locally with Docker.

[marcoienibot]

Review round 1

Two review passes (correctness/tests/security, and maintainability/simplicity) produced 16 findings. I applied 10 as one commit each and skipped 6. The merged branch passes cargo fmt, cargo clippy -D warnings, and the full Docker run (PASS: created a Gitea release PR and returned matching outputs).

Commits

Commit	What	Why
6ac6b63 test: use a fixed compose project name	Project is now release-plz-gitea-test; the harness runs compose down at start as well as in Drop; fixed (fake) registration token and admin password; getrandom dependency removed.	Drop never runs on Ctrl-C/SIGKILL, and random names meant leaked stacks and images could never be reclaimed. The random name was also the reason --rmi local had to be added. Trade-off: one run per host at a time.
6de158f test: push the Gitea fixture with URL-embedded credentials	git push --atomic http://user:token@host/... instead of remote add + a base64 Basic header via GIT_CONFIG_* env vars; base64 dependency removed.	The local remote was never used (the job clones fresh from Gitea) and git already strips passwords from URLs in its output.
38142a0 test: check the Gitea release PR from the harness only	Removed the curl | jq block from the fixture workflow; the harness now also asserts base.ref == main and head.ref starts with release-plz-.	Both sides asserted "one open PR titled chore: release v0.1.1". The workflow now owns only what the job can see (step outputs); the harness owns what happened on the forge.
72d7e0b refactor: flatten the Gitea API client	text/request/get became send (status-checked Response) + get (JSON); the empty-body-to-Null special case and the immediately-invoked closure in print_job_logs are gone.	Mutating callers discarded the parsed body; the layering existed only for them.
1cce5c2 refactor: make names in the Gitea test mean one thing	repo is always owner/name; Gitea stores the address and derives /api/v1; Stack -> Compose, admin -> admin_user.	wait_for_workflow took an API path in a parameter called repo, and address was threaded as a third parameter next to a struct that already held the URL.
27a0580 test: wait for Gitea runner registration in compose	Runner service healthcheck on /runner/.runner.	up --wait returned while gitea-runner register was still running, so a registration failure surfaced only after the 15-minute poll. Verified: up --wait now reports runner-1 Healthy.
37dc099 build: ignore the whole Gitea runner build context	tests/gitea/.dockerignore with *.	The Dockerfile copies nothing from the context, but the harness's own target/ lives inside it and the classic builder would ship it on every run.
21e3d89 test: check out the Gitea fixture with actions/checkout	Replaced the 12-line manual clone + .extraheader step with actions/checkout@v5.0.1 (token, fetch-depth: 0) plus a git config step.	This is the path real users take, so the test now exercises it. v7 failed: since v6, checkout stores the token in a file scoped to the workspace .git via includeIf, so release-plz's temp copy could not push (release-plz/release-plz#2957). v5.0.1 is the newest release that writes .extraheader into .git/config; the YAML comment explains this.
2e2030a build: drop xz-utils from the Gitea runner image	Removed the apt package.	install-action installs it itself if it meets a .tar.xz, and cargo-semver-checks ships .tar.gz. Confirmed by a passing run.
b6a7cdb docs: trim the Gitea integration test READMEs	Root README links to tests/gitea/README.md instead of duplicating the command; the test README now lists prerequisites, the command, what is asserted, the fixed project name, and the manual down command.	The old text documented implementation details (generated credentials, random project) that the commits above made wrong.

Skipped

• Rewrite the harness as a shell script. The maintainability reviewer's strongest point: the Rust crate uses untyped Value indexing and straight-line control flow, so bash + curl + jq (as the rest of this repo's CI already uses) would be ~100 lines with no build step and no lockfile for renovate to churn. I did not do it because the Rust harness is the deliberate shape of this PR and replacing it is a scope decision for you. The dependency diet above (99 to ~52 locked packages) is the second-best outcome the reviewer suggested.
• Replace reqwest with shelling out to curl. Would cut the lockfile to ~26 packages and remove most compile time, but shelling out for HTTP from a Rust harness is awkward, and the ~1 minute compile is acceptable in CI.
• GITHUB_TOKEN (the Gitea token) is sent to api.github.com by cargo-binstall. This is real and pre-existing in action.yml, not introduced here: the uses: ./ step's env is inherited by the "Install release-plz" step, and cargo-binstall 1.23 reads GITHUB_TOKEN and sends it as a Bearer token to GitHub, only falling back to anonymous after a 401. taiki-e/install-action unsets it correctly. Worth its own issue/PR (blank the token for the install step when the forge is not GitHub, or pass --no-discover-github-token plus an empty --github-token).
• Assert the PR head's Cargo.toml literally contains version = "0.1.1". The title, the releases[0].version output, and the changed-files check already cover it; a stricter check would be testing release-plz, not the action.
• Hand-rolled copy_dir. 12 straightforward lines; a dependency or cp -r is not simpler.
• Cosmetic nits: putting the gitea CI job after test, a single target/ gitignore pattern, a root Cargo workspace, dropping description/license from the fixture manifest. None change behaviour.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AhCChWJ9X6ryPuuPLF8Ggx

[marcoienibot]

Review round 2

Both reviewers re-ran on b6a7cdb. The correctness/security pass found nothing significant and verified the round-1 changes against upstream sources (compose down on a missing project, git URL anonymisation on every output path, the gitea/runner host-mode node lookup, the .runner write happening only after successful registration, Gitea PR JSON field names). The maintainability pass found one real leftover from the old design plus a stale README sentence. Three commits, all verified with a passing Docker run; CI on the previous push also passed.

Commits

Commit	What	Why
f783113 test: name the Gitea compose project in compose.yml	Top-level name: release-plz-gitea-test and the registration token inlined once via a YAML anchor; Compose::PROJECT, Compose::REGISTRATION_TOKEN, -p, and the env injection are gone from the harness. README's manual cleanup is now docker compose -f tests/gitea/compose.yml down --volumes.	The ${GITEA_RUNNER_REGISTRATION_TOKEN:?} indirection existed to inject generated values. With constants it only made every hand-run docker compose -f tests/gitea/compose.yml ... fail with "required variable ... is missing a value".
a454138 docs: describe what each side of the Gitea test asserts	README no longer says the workflow checks outputs "against the pull request Gitea reports".	Since 38142a0 the workflow only checks the step outputs; only the harness queries Gitea.
7198e94 test: drop redundant shell keys from the Gitea fixture workflow	Removed two shell: bash lines.	Run steps default to bash with -e -o pipefail; only composite actions need shell:.

Corrections to my round-1 comment

• I wrote that removing getrandom and base64 cut the lockfile "99 to ~52 packages". That was wrong: both remain as transitive dependencies of tempfile and reqwest, so the lockfile still has 99 entries. The commits removed two direct dependencies and the code that used them, nothing more.
• I wrote that actions/checkout v5.0.1 "is the newest release that writes .extraheader into .git/config". Also wrong: v5.1.0 still does; the includeIf credential file only arrived in v6.0.0. The pin and the YAML comment are correct, and bumping to v5.1.0 would be optional.

Skipped

• Reword the checkout comment to lead with "Pinned to v5.0.1" and Duration::from_mins(15): pure wording preferences.
• Drop --rmi local now that the project name is fixed: keeping it costs one cached rebuild per run and leaves the host clean, which was the explicit reason it was added in f952ed7.
• ::add-mask:: for a throwaway token: harmless; keeping it means nothing token-shaped ends up in CI logs.
• Both reviewers confirmed the Configure git user step and all five apt packages (ca-certificates curl git jq nodejs) are needed, and that the reqwest json feature is still used.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AhCChWJ9X6ryPuuPLF8Ggx

[marcoienibot]

Review round 3

Both reviewers re-ran on 7198e94. One low-severity gap introduced by round 2, one stale name left over from round 1, and one small structural simplification. Three commits, verified with a passing Docker run (this time with COMPOSE_PROJECT_NAME=should-be-ignored exported to prove the first fix).

Commits

Commit	What	Why
cee86d8 test: ignore COMPOSE_PROJECT_NAME in the Gitea harness	Compose::command() removes COMPOSE_PROJECT_NAME from the environment of every docker compose call.	Compose precedence is -p > COMPOSE_PROJECT_NAME > top-level name:. After round 2 dropped -p, a developer with that variable exported would have had the harness's down --volumes --rmi local run against their own project, and the "next run cleans up" promise would have depended on the shell. Verified: with the variable set, compose config reports the overridden name, but the test's containers are still release-plz-gitea-test-*.
acba1bc test: rename the Gitea fixture's output check step	Check action outputs against Gitea is now Check action outputs.	The step stopped querying Gitea in 38142a0; it compares outputs with literal expectations.
e904c62 refactor: make the Gitea test directory a constant	Compose.directory (always CARGO_MANIFEST_DIR) became a const; Compose is now just the passed flag and test_release_pr takes only &Gitea.	Removed a runtime field that was a compile-time constant and a false parameter dependency.

Correction to a round-2 commit message

The body of 7198e94 says run steps default to bash with -e -o pipefail. On gitea/runner 3.4.2 an implicit shell runs as bash -e {0} without pipefail (matching GitHub's runner); the full flag set only applies when shell: bash is explicit. The outcome is unchanged because the step sets set -euo pipefail itself, which is exactly why that line was kept.

Skipped

• Name the Gitea repo after the fixture crate or hoist "forge" into a constant: cosmetic.
• Reword the compose.yml comment above name: ("Fixed so that..." could read as "bug-fixed"): placed directly above name: it reads as intended.
• Both reviewers otherwise concluded the branch is at the point where further changes would be churn.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AhCChWJ9X6ryPuuPLF8Ggx

[marcoienibot]

Review round 4

Both reviewers re-ran on e904c62. The correctness pass probed every compose environment knob (COMPOSE_FILE, .env, COMPOSE_PROFILES, COMPOSE_COMPATIBILITY, DOCKER_HOST) and found one more that could redirect down; the maintainability pass found nothing dangling from round 3 and one optional reshaping. Two commits, verified with a passing Docker run with COMPOSE_ENV_FILES deliberately exported.

Commits

Commit	What	Why
b86f5d7 test: ignore COMPOSE_ENV_FILES in the Gitea harness	Compose::command() also removes COMPOSE_ENV_FILES from the environment.	A COMPOSE_PROJECT_NAME= entry in a file named by that variable beats the top-level name: exactly like the exported variable does, so a developer using it for their own stack would have had the harness's down --volumes --rmi local target that stack. Verified: with the variable set, compose config reports the file's name, but the test's resources are still release-plz-gitea-test-*.
03c6efa refactor: start the Gitea compose stack from a constructor named for it	Compose::new() became Compose::up() and owns the docker compose up ... --wait call after the initial down().	A new that ran a docker side effect needed a comment to explain itself; up/down are now symmetric and the test body starts at the first step that yields a value. Behaviour is identical, including logs + down on a failed up.

Skipped

• Pass --env-file /dev/null or reinstate -p as broader alternatives: removing the two variables is minimal and keeps the name in one place. A stray tests/gitea/.env would still override it, but that file is not in the repo and would show up in git status.
• Make command() an associated function (clippy pedantic unused_self): it exists for call-site grouping on a Drop guard.
• Drop --detach next to --wait: redundant but explicit.

The maintainability reviewer's verdict: apart from the reshaping above, the harness is as simple as it reasonably gets and another round would be churn. One more round will confirm that.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AhCChWJ9X6ryPuuPLF8Ggx

[marcoienibot]

Review round 5

Both reviewers re-ran on 03c6efa. The correctness pass verified the round-4 changes (a failed up still dumps logs and tears down via Drop; the doc comment matches the body) and swept the whole diff again with nothing to report. The maintainability pass found nothing dangling in the diff itself, but one real interaction with the repo's Renovate config.

Commit

Commit	What	Why
584ff0e chore(renovate): keep the Gitea fixture on checkout v5	A packageRules entry restricting actions/checkout under tests/gitea/fixture/.gitea/workflows/** to v5.*.	Renovate's github-actions manager scans .gitea/workflows paths, this repo does not exclude tests/, and all action updates are grouped into one automerged weekend PR. Without the rule Renovate would bump the fixture's deliberately pinned checkout v5.0.1 to v7 every weekend, the gitea job would fail (checkout v6+ breaks release-plz's push, release-plz/release-plz#2957), and the whole grouped automerge would be blocked. Digest refreshes and moves within v5 stay allowed. renovate-config-validator passes.

Skipped

• README says "Compose v2 or newer" while up --wait-timeout, top-level name:, and COMPOSE_ENV_FILES need later 2.x releases: no supported Docker ships anything older, and an old CLI fails with a usage error rather than a confusing one.
• Manual down --volumes in the README omits --rmi local: the next test run removes the image anyway.
• Double down when the initial cleanup itself fails: two lines of noise on a path that only fires when Docker is broken.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AhCChWJ9X6ryPuuPLF8Ggx

[marcoienibot]

Review round 6

Both reviewers re-ran on 584ff0e. The correctness pass verified the Renovate rule against Renovate's current source (matchFileNames is the live key and the glob matches through .gitea; the regex allowedVersions filters raw tag names independently of versioning, so v5.1.0 and digest refreshes of v5.0.1 stay allowed while v7.x is blocked; rule order does not matter because no option overlaps the group rule) and found nothing else. The maintainability pass found one comment-level issue.

Commit

Commit	What	Why
a274e24 docs: cross-reference the Gitea fixture checkout pin and its Renovate rule	The Renovate rule's comment now just points at the fixture's checkout step and the issue; the fixture's comment gains one line pointing back at the rule and saying to drop it when bumping. Comment-only.	Both places explained the v6 mechanism in different words, and the Renovate wording was the looser one. More importantly, when release-plz/release-plz#2957 is fixed and someone bumps the pin, nothing would tell them the rule exists, and it would silently freeze the fixture at the new major.

Skipped

• allowedVersions: '<6' instead of the regex: works only through a logged fallback to npm semver; the regex is the primary path and explicit.
• Widen the rule's path glob to tests/gitea/**: the precise path documents where the pinned workflow lives.

Both reviewers state the branch is as simple as it reasonably gets and further rounds would be churn. One more scoped round on this comment-only commit closes the loop.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AhCChWJ9X6ryPuuPLF8Ggx

[marcoienibot]

Review round 7 (final)

Both reviewers re-ran on a274e24. Correctness confirmed the last commit is comment-only (both files parse; the fixture workflow parses to the same YAML document as before) and found nothing new across the full diff. Maintainability found nothing worth a commit. No further rounds.

Final state: 4 original commits plus 20 review commits, every one verified locally with cargo fmt, cargo clippy -D warnings, and (for every non-docs change) a passing Docker run of the integration test. The one item worth a separate issue remains the pre-existing action.yml behaviour where cargo-binstall receives the forge token via GITHUB_TOKEN and sends it to api.github.com when forge is not GitHub.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AhCChWJ9X6ryPuuPLF8Ggx

[marcoieni]

Update all dependencies to the latest version