Dockstore Release

Dockstore Release

Guides a webservice release for dockstore/dockstore, based on the dockstore-deploy wiki page "Dockstore Releases" (webservice / "Friendly CI versions and a GitHub Action" section), adjusted for what the team actually does in practice — see Notes / gotchas below for where practice diverges from the wiki text.

This process touches shared state (git tags, branches, Artifactory, quay.io images, and potentially master). Never run the build/tag/push/finish commands without showing the exact command first and getting explicit confirmation — treat this the same as any other hard-to-reverse, shared-state action.

Step 0 — Ask the two key questions

Ask up front, via AskUserQuestion:

1. Tag name — the exact version to release, e.g. 1.21.0-alpha.6, 1.21.0-beta.0, 1.21.0, or a hotfix like 1.20.1.
2. Unstable or stable?
   • Unstable: any alpha/beta/rc prerelease tag.
   • Stable: a final X.Y.Z tag (no prerelease suffix) or a hotfix release.
   • Don't infer this from the tag string alone — confirm explicitly, since it changes the entire back half of the process (see Step 3 vs Step 4).

If it's not obvious from context, also confirm whether this is a release (branched from develop) or a hotfix (branched from master).

Step 1 — Reconnaissance before touching anything

Before running any command, check and report findings to the user:

• git status on the current checkout — must be clean before starting.
• git fetch origin --tags, then confirm the target tag doesn't already exist (git tag -l "<tag>", gh release view <tag> --repo dockstore/dockstore). If it exists, stop and ask rather than overwriting/re-tagging.
• Look for stale release/*/hotfix/* branches (local and origin/) that might collide with or be confused for the new branch. If any look abandoned, confirm with the user before deleting (git branch -d/-D, git push origin --delete) — don't delete unasked.
• Read <revision>/<changelist> in the root pom.xml to sanity-check against the target version (normally sits at .0-SNAPSHOT on develop).

Step 2 — Present the plan, then execute with checkpoints

Show the full tailored command sequence (below, with the real tag substituted) before running anything. Then execute step by step:

• Read-only checks (git status, log, tag/branch lookups) can run without asking each time.
• Anything that mutates shared state — git hf release start/finish, the mvnw build, git commit, git tag, git push, branch deletion, drafting/publishing a GitHub Release — gets a confirmation checkpoint first. Batch tightly-coupled steps (e.g. commit+tag+push) into one confirmation once the diff has been shown, rather than asking before every single command.

Step 3 — Unstable release path (alpha/beta/rc)

git checkout develop && git pull        # or master, for a hotfix
git hf release start <tag>              # or: git hf hotfix start <tag>

./mvnw clean install -Dchangelist=<suffix> -DskipTests
git add dockstore-webservice/src/main/resources/openapi3/openapi.yaml **/generated/**/pom.xml
git commit -m "Update artifacts"
git tag <tag> -a -m "release process"
git push origin <tag>
git push origin release/<tag>

<suffix> is the changelist override that reproduces the tag, i.e. everything after <revision> in the version string — tag 1.21.0-alpha.5 (with <revision>1.21</revision>) means -Dchangelist=.0-alpha.5.

Before committing, verify the build only touched dockstore-webservice/src/main/resources/openapi3/openapi.yaml and each module's generated/src/main/resources/pom.xml — if anything else changed, stop and ask.

Then:

• Watch the Deploy artifacts action run to completion: gh run list --repo dockstore/dockstore --workflow=deploy_artifacts.yml, then gh run view <run-id> --repo dockstore/dockstore. It publishes to OICR Artifactory and pushes a Docker image to quay.io/dockstore/dockstore-webservice.
• Confirmed team practice: that's the whole release. Despite the wiki describing a "Reset version" commit + merge of the release branch back into develop, in practice this is skipped for unstable tags — leave release/<tag> as pushed, don't reset generated files, don't merge it anywhere, and don't draft a GitHub Release, unless the user explicitly asks for one of those. Never run git hf release finish for an unstable tag.