feat: reset all Jobs to a single pinned 2.0.0 release

[tdudgeon]

Closes #34.

Moves the whole repository off the mutable stable/latest tags and onto a single immutable release tag, so the Jobs can be wiped from the Data Manager and re-loaded as one coherent, reproducible set.

What changed

Area	Change
data-manager/ (8 files)	All 48 Job Definition version values → '2.0.0' (were 38 × 1.0.0, 8 × 1.0.1, 2 × 1.0.2); the 46 image.tag values for our images → '2.0.0'
nf-processes/ (22 files)	All 28 container 'informaticsmatters/…' directives → :2.0.0
5 Dockerfiles	FROM informaticsmatters/vs-rdkit-base:latest → :2.0.0 (-fns, -moldb, -mordred, -oddt, -prep)
.github/workflows/publish-tag.yaml	New. Manually dispatched, takes an image-tag input, calls the existing build-all-with-push-option.yaml with image-push: true
.github/workflows/test.yaml	Adds jote --manifest manifest-moldb.yaml --dry-run
moldb/k8s-create-tables.yaml, README.md, USER_GUIDE.md, docker-compose.yaml	Tag references and build docs brought in line

Why 2.0.0 and not 1.0.0

informaticsmatters/vs-prep:1.0.0, vs-nextflow:1.0.0 and vs-rdock:1.0.0 already exist on Docker Hub (pushed 2021-06), and git tags 1.0.0–1.0.11 are already taken here. The DM treats any tag other than latest/stable as static and caches it per Kubernetes node, so republishing 1.0.0 would leave some nodes silently running 2021 code. 2.0.0 is unused across all 11 images and the base — verified against the Docker Hub tags API.

Deliberately unchanged

• 3dechem/silicos-it:latest — third-party, and latest is the only tag it has ever published (2017-08-15). The two silicos-it Jobs move to version 2.0.0 but keep that image tag, and stay non-reproducible. The existing explanatory comment is untouched.
• build.yaml, publish-latest.yaml, publish-stable.yaml — the latest/stable development loop still has value for the non-Nextflow images.
• euclia/jaqpotpy-inference:1.1.0, informaticsmatters/rdock:2013.1, python:3.10.12-slim-bullseye, debian:bullseye — already pinned.
• kind-version: '2021.1' — schema version, not a Job version.

Known consequence

nf-processes/ is COPY'd into the vs-nextflow image, so these tags are baked in at build time. The latest/stable vs-nextflow images built from staging/main will now also spawn :2.0.0 process containers, which makes the dynamic-tag development loop incoherent for Nextflow Jobs. Accepted for now; the clean fix (a Nextflow params value) is a follow-up noted in #34, complicated by nextflow.config not being shipped in the image.

Release sequence after merge

1. Build and push informaticsmatters/vs-rdkit-base:2.0.0 by hand — five images are FROM it and the CI build fails without it.
2. Merge.
3. Run publish-tag from main with image-tag: 2.0.0; confirm all 11 images appear on Docker Hub.
4. Create and push the git tag 2.0.0. Never move it.
5. Once the old Jobs are cleaned out of the DM, hand administrators the tag-pinned manifest URLs, e.g. https://raw.githubusercontent.com/InformaticsMatters/virtual-screening/2.0.0/data-manager/manifest-im-virtual-screening.yaml.

Verification done

• jote --dry-run passes against all six manifests: fragnet-search 3/3, im-virtual-screening 32/32, silicos-it 0/0, dmpk 1/1, im-mordred 2/2, moldb 12/12. (moldb passes without --allow-no-tests, so it is added to CI unqualified.)
• Sweep is complete — tag: 'stable', version: '1.0., :stable under nf-processes/, and vs-rdkit-base:latest all return nothing. Counts confirmed at 48 / 46 / 2 / 28.
• 2.0.0 confirmed absent from Docker Hub for every image, including the base.
• The # tag: … line in the guide comment block at data-manager/im-virtual-screening.yaml:40 was not touched by the sweep.

Not yet done: no 2.0.0 image exists anywhere yet, so nothing has been run against a real 2.0.0 container. Step 1 and 3 above have to happen before an end-to-end jote run (particularly a Nextflow Job such as run-rdock or moldb-load-library, which is what proves the baked-in process container tags resolve).

🤖 Generated with Claude Code