ci: consolidate release onto GitHub Actions and drop Woodpecker

[slayerjain]

Why

This repo was running two CI systems in parallel. Some of it was pure duplication, and the rest was split across the two in a way that made releases fragile.

The build pipeline was 100% redundant. .woodpecker/build.yml and .github/workflows/java-agent.yml ran identical commands on an identical JDK 8/17/21 matrix (mvn -B -DskipTests clean verify + ./scripts/smoke-javaagent.sh). Every PR and every push to main built the project twice. This was introduced by accident: f70e488 deliberately migrated off GitHub Actions to Woodpecker, then 8d48e62 re-added GitHub Actions three days later without removing the Woodpecker half.

The release was split across both systems. Woodpecker published to Maven Central; GitHub Actions published the GitHub Release. Both fired independently off the same tag with nothing coupling them, so the jar attached to the GitHub Release was a separate, unsigned build of the one on Central. Verified on v2.1.0: the two jars have different SHA-256 sums. (The contents are fine — all 2274 entries match by CRC, the difference is only build timestamps — but consumers had no way to establish that, and no signature to check.)

Since this is a public repo, PR checks belong where contributors can actually see them.

Correction to an earlier version of this description, which claimed v2.0.6 reached GitHub but not Central. That was wrong, and worth stating plainly because it drove the original design. v2.0.6 is on Central and always was — jar, sources, pom and signatures all present. What failed on that release was the Woodpecker wait step, via the ${VERSION} templating bug fixed in c1b96c1; the deploy had already succeeded. The real incident was cosmetic. That correction changed the design (see below).

What changed

Woodpecker is removed entirely and its Central publishing is folded into the release workflow, now split into two jobs:

publish          build -> sign -> smoke test -> stage assets -> deploy to Central
github-release   wait for repo1 -> create the GitHub Release

Publishing to Central is irreversible and non-idempotent — the Portal rejects a re-upload of an existing version — so everything that can fail cheaply runs before it, and the deploy is the last step of its job. Everything after it lives in a separate job that can be re-run on its own.

This is a direct consequence of the correction above. A single job would have taken v2.0.6's cosmetic failure (deploy fine, wait step failed) and made it unrecoverable: the job would go red after an irreversible publish, and re-running it could only re-attempt a deploy Central now rejects, permanently stranding the GitHub Release. Now a slow repo1 sync fails only github-release, which re-runs independently against the staged assets carried over as a workflow artifact. workflow_dispatch is added as a manual recovery path, and a concurrency group stops two releases of the same ref overlapping (cancel-in-progress: false — cancelling mid-deploy is the one thing that could strand a release).

The jar that ships is the jar that was smoke tested. The deploy reuses target/ without cleaning, and shade is idempotent here, so the published artifact is byte-identical to the one tested — verified locally against a real signed build.

Nothing Woodpecker did is lost: GPG import, the central server credentials, mvn -P release deploy, and the repo1 poll all carried over. The ${VERSION}-vs-$VERSION workaround (c1b96c1) is gone — that was a Woodpecker templater quirk.

Hardening

• Shell injection fixed. Git accepts backticks and semicolons in ref names and v*.*.* matches them, so an unquoted tag interpolated into the Maven arguments was injectable by anyone with push access — in a job holding the Central signing key. The version is now validated against ^[0-9]+\.[0-9]+\.[0-9]+(-[A-Za-z0-9.]+)?$ before the key is imported.
• Signatures are required, not optional. The previous nullglob guard meant a signature-less build would publish a green, unverifiable GitHub Release. An unmatched glob now fails the job, and pom signatures + the parent pom are staged too (the old *.jar.asc glob skipped them), so the assets are verifiable and usable offline.
• versions-maven-plugin pinned to 2.21.0. Unqualified versions:set resolved the latest plugin from Central at run time, executing unreviewed code in the job holding the signing key.
• -Dgpg.passphrase dropped from argv — setup-java's gpg-passphrase already wires the server entry maven-gpg-plugin reads; passing it again only exposed it in the process table.
• Timeout budget corrected. The pom's waitMaxTime=7200 is 120 minutes on its own, so a single 150-minute cap could not cover it plus the build plus the 30-minute poll.
• --max-time on the repo1 poll; a release left as a draft by an interrupted run is now promoted.
• Restored CI for PRs not targeting main. Woodpecker ran the matrix on every PR regardless of target; the branches: [main] filter silently dropped coverage for this repo's long-lived integration branches.

Recovery (second review pass)

The two-job split let a failed github-release be re-run without re-deploying, but the deploy itself was not idempotent — so any whole-run retrigger (re-pushed tag, Re-run all jobs, or the workflow_dispatch advertised as the manual recovery path) re-ran mvn deploy against an already-published version, got rejected, and skipped github-release. The documented recovery path could never produce the release it existed to rescue, and Re-run all jobs additionally deletes the run's artifacts, destroying the validated assets the safe path depends on.

The deploy is now guarded by a check against Central and skipped when the version is already published, so every retrigger converges on the same end state.

• overwrite: true on the artifact upload — v4 names are immutable within a run and partial re-runs don't clear them, so re-running a publish that failed at the deploy would have 409'd at the upload, before reaching the step that failed.
• Repo1 poll bounded by elapsed time, not iterations. With --max-time 30 per request, 60 iterations could run a full hour against a 45-minute job timeout — the actionable "re-run this job" message would never print.
• Version guard corrected: it rejected legal pre-release tags with a hyphen (v2.1.0-alpha-1) and accepted SNAPSHOT and leading zeros, where v02.1.0 would irreversibly publish a coordinate distinct from v2.1.0.
• Concurrency group added to java-agent.yml so superseded PR runs cancel, now that its trigger is unfiltered.
• Corrected the "byte for byte" claim: the agent and sources jars are identical across the two lifecycle passes (jar:jar and source:jar-no-fork skip as up-to-date); the javadoc jar differs by its embedded generation timestamp — content-equivalent, and carries its own signature.

⚠️ Before merging — repository secrets

The release workflow needs these four secrets, which currently live only in Woodpecker. Names map 1:1 (uppercased, and the space in central password fixed):

Woodpecker	GitHub secret
maven_gpg_private_key	MAVEN_GPG_PRIVATE_KEY
maven_gpg_passphrase	MAVEN_GPG_PASSPHRASE
central_username	CENTRAL_USERNAME
central password	CENTRAL_PASSWORD

MAVEN_GPG_PRIVATE_KEY must be the ASCII-armored private key (gpg --armor --export-secret-keys 8541784E4EC36FB8); actions/setup-java has none of the base64 / escaped-newline fallback logic the Woodpecker script carried.

Only tag builds are affected, so merging does not break PR CI — but the next release fails if the secrets aren't in place. The failure is safe: with no key, the build dies at gpg:sign during verify, before anything is uploaded.

Housekeeping

• Four stale secrets from June 2024 remain (GPG_PRIVATE_KEY, GPG_PASSPHRASE, MAVEN_USERNAME, MAVEN_PASSWORD) from the pre-Woodpecker OSSRH workflow. I deliberately did not reuse these names so a dead credential can't cause a confusing release failure. Worth deleting, along with the inert repository environment also named GPG_PRIVATE_KEY.
• After merge, remove the Woodpecker repo hook and its four secrets. Those secrets are currently scoped to pull_request events on a public repo with PR builds enabled — worth confirming whether fork PRs required approval, and rotating the signing key is a cheap precaution while decommissioning either way.

Testing

All run locally on this branch:

• mvn -B -ntp -DskipTests clean verify and ./scripts/smoke-javaagent.sh — pass (all 5 scenarios)
• Full signed release build with a throwaway GPG key — confirms the release profile produces and signs the main, -sources, -javadoc and pom artifacts, plus the parent pom, and that the smoke test passes against the signed build
• Confirmed setup-java's passphrase mechanism works standalone — signing succeeds with the passphrase supplied only via the gpg.passphrase server entry, no -Dgpg.passphrase
• Confirmed the shipped jar is the tested jar — re-ran the lifecycle without clean against a signed build; identical SHA-256
• Staging step executed verbatim against the signed build: 12 assets, every .jar/.pom with a matching .asc, all signatures verifying Good signature
• Failure paths exercised: a missing signature and a fully absent .asc glob both exit non-zero
• Version guard exercised: accepts v2.1.0, v2.0.6-rc1, v10.20.30; rejects v1.0.0;`id` , v1.0.0;touch$IFS/tmp/x, v1.0.0 && id, main, v1.0
• Every run: block syntax-checked with bash -n; both workflow files parsed