Releasing — Quarkus TUS

Five artifacts are published under org.sitenetsoft; integration-tests is not:

Coordinates Contents

Coordinates	Contents
`quarkus-tus`	Server runtime. Applications that accept uploads declare this one.
`quarkus-tus-deployment`	Build-time augmentation for the server. Resolved by Quarkus from the runtime jar’s `META-INF/quarkus-extension.properties`; never declared directly.
`quarkus-tus-client`	Client runtime (`TusProtocolClient`, `TusClient`). Independent of the server; see TUS Client.
`quarkus-tus-client-deployment`	Build-time augmentation for the client. Resolved the same way; never declared directly.
`quarkus-tus-tck`	`AbstractUploadStoreContractTest` for authors of a custom `UploadStore`; test scope only. See the contract test.

quarkus-tus

Server runtime. Applications that accept uploads declare this one.

quarkus-tus-deployment

Build-time augmentation for the server. Resolved by Quarkus from the runtime jar’s META-INF/quarkus-extension.properties; never declared directly.

quarkus-tus-client

Client runtime (TusProtocolClient, TusClient). Independent of the server; see TUS Client.

quarkus-tus-client-deployment

Build-time augmentation for the client. Resolved the same way; never declared directly.

quarkus-tus-tck

AbstractUploadStoreContractTest for authors of a custom UploadStore; test scope only. See the contract test.

Important

The artifact ids must stay exactly as above. Each runtime jar’s descriptor names its deployment artifact, and Quarkus resolves the deployment module from it at augmentation time. Renaming a module without updating the other breaks every consumer at build time, not at runtime. The ids live in one place, the publishedArtifactIds map in the root build.gradle; the descriptors and the deployment coordinates are derived from it.

The release workflow

.github/workflows/release.yml publishes to the Central Portal. It runs when a v* tag is pushed, and can also be dispatched by hand from master only.

It refuses a -SNAPSHOT version, and on a tag push refuses a tag that does not match the version in build.gradle. Set the version first, commit, then tag: git tag v1.0.0 && git push origin v1.0.0.
It runs the full build and the integration tests, with MinIO so the S3 store suites run rather than skip.
It signs every jar and POM and lays the five artifacts out as a Portal bundle (build/staging-deploy, zipped to build/central-bundle.zip, also kept as a workflow artifact for 30 days).
It uploads the bundle and polls the Portal until the deployment is validated or fails.
On a tag it creates the GitHub release with generated notes.

Secrets it needs

Secret Purpose

Secret	Purpose
`SIGNING_KEY`	ASCII-armoured private PGP key: `gpg --armor --export-secret-keys KEY_ID`. Its public half must be on a key server (`keyserver.ubuntu.com` or `keys.openpgp.org`), or Central rejects the signatures.
`SIGNING_PASSWORD`	The key’s passphrase.
`CENTRAL_USERNAME`, `CENTRAL_PASSWORD`	A Central Portal user token (Portal → View Account → Generate User Token), not the account password. The `org.sitenetsoft` namespace must be verified on the Portal for the token’s account.

SIGNING_KEY

ASCII-armoured private PGP key: gpg --armor --export-secret-keys KEY_ID. Its public half must be on a key server (keyserver.ubuntu.com or keys.openpgp.org), or Central rejects the signatures.

SIGNING_PASSWORD

The key’s passphrase.

CENTRAL_USERNAME, CENTRAL_PASSWORD

A Central Portal user token (Portal → View Account → Generate User Token), not the account password. The org.sitenetsoft namespace must be verified on the Portal for the token’s account.

Nothing in the build stores credentials; local builds need none, since signing is skipped when no key is present and for -SNAPSHOT versions.

Publishing type

A tag push uploads with publishingType=USER_MANAGED: the deployment stops at validated and nothing reaches Central until someone presses Publish at https://central.sonatype.com/publishing/deployments. The workflow marks this with a warning and creates the GitHub release as a draft, so the tag never advertises artifacts that are not downloadable; publish the draft after releasing the deployment. A manual dispatch can choose AUTOMATIC, which releases immediately and cannot be undone.

Checking before you publish

./gradlew publishToMavenLocal

This writes all five artifacts to ~/.m2/repository/org/sitenetsoft/. Then build a sample application against the local repository, declaring only org.sitenetsoft:quarkus-tus:1.0.0 (and the client if you use it), to confirm the extension resolves, augments, and that your code compiles against the SPI. That is the check that catches an artifact id or descriptor mistake before a consumer does.

To inspect the exact bundle the workflow would upload, without credentials:

./gradlew publishAllPublicationsToStagingRepository
find build/staging-deploy -type f | sort

Documentation site

The pages in docs/modules/ROOT are published at https://sitenetsoft.org/quarkus-tus/ by .github/workflows/pages.yml, which runs on every push to master that touches docs/. The site is generated by docs/site/build.js with asciidoctor.js: one HTML page per .adoc in the order of nav.adoc, styled to match sitenetsoft.org. The build fails on any xref whose target page or anchor does not exist, so a broken link never reaches the published site. To build it locally:

cd docs/site && npm ci && npm run build

Then open build/site/index.html at the repository root. The Antora layout is untouched by this, so the same pages can be aggregated by an Antora site later.