ci: add rustyrazorblade/cassandra-6.0-rustyrazorblade fork to the nightly build matrix

[rustyrazorblade]

Summary

• Add an explicit repo: field to all 3 existing matrix entries (previously implicit apache/cassandra default) so the matrix is self-documenting once entries diverge.
• Add a 4th matrix entry: repo rustyrazorblade/cassandra, ref cassandra-6.0-rustyrazorblade, stable_version 6.0-rustyrazorblade-HEAD.
• Update the publish-nightly release notes body to list the new build in both the tracked-build bullet list and the Stable Download URLs block.

Validated by manually dispatching the reusable build-cassandra-ref.yml engine directly against the fork (repo=rustyrazorblade/cassandra, ref=cassandra-6.0-rustyrazorblade) — build + Docker image + CQL smoke test all passed: https://github.com/rustyrazorblade/easy-db-lab/actions/runs/30406460393

Second commit: wire the fork into the lab's own AMI-bake install path

• Add a version: "6.0-rustyrazorblade" entry to packer/cassandra/cassandra_versions.yaml (java 21, python 3.11.9), pointing url/branch at rustyrazorblade/cassandra / cassandra-6.0-rustyrazorblade.
• This is a distinct concern from the GitHub Actions matrix above: it lets install_cassandra.sh git-clone and ant-build this branch directly when baking the lab's Cassandra AMI (easy-db-lab build-cassandra), the same git-build mechanism already used for custom builds documented in docs/user-guide/installing-cassandra.md.
• Validated structurally only (YAML parses, no version key collision with existing entries). No AMI bake was run as part of this change — that's a separate, deliberately deferred step.

Third commit: document the new version in the supported-versions table

• Add 6.0-rustyrazorblade to the "Supported Versions" table in docs/user-guide/installing-cassandra.md, positioned after 6.0-HEAD, labeled as a personal fork build (not an official/nightly build) to avoid confusion with the 6.0-HEAD nightly row above it.
• Update the two other docs pages that enumerate the same closed version list (docs/user-guide/tutorial.md, docs/reference/commands.md) so they stay consistent with the table.

[github-actions]

Code Coverage

Total Project Coverage	73.48%	❌

[claude]

Review

Small, well-scoped CI change — explicit repo: per matrix entry plus a 4th entry for the rustyrazorblade/cassandra fork. The reusable build-cassandra-ref.yml engine already supported an arbitrary repo input (default apache/cassandra), so this is just wiring the matrix + docs up to use it, with no changes to the resolve/build/publish logic itself. Nice touch validating it with a real manual dispatch run before opening the PR.

Code quality

• The repo field addition is consistent across all 4 matrix entries and the comment explaining why (self-documenting now that not every entry is from apache/cassandra) is a good example of a "why, not what" comment per repo convention.
• Release notes body (tracked-build bullet list + Stable Download URLs block) was updated in both places and stays consistent with the existing 3 entries' formatting.
• version: "6.0-rustyrazorblade-HEAD" is properly quoted, avoiding the YAML-float footgun called out in the existing comment above the matrix.

Potential gaps (not blockers, just flagging)

• packer/cassandra/cassandra_versions.yaml has no entry for 6.0-rustyrazorblade-HEAD, so the new nightly tarball this workflow publishes won't be consumable via the normal cassandra use <version> install path yet — it'll just sit in the nightly release. If the intent is for this build to eventually be installable in a lab cluster (not just published), that'll need a follow-up entry pointing at .../releases/download/nightly/apache-cassandra-6.0-rustyrazorblade-HEAD-bin.tar.gz (mirroring the 5.0-HEAD/6.0-HEAD/trunk entries). Worth confirming whether that's intentionally out of scope for this PR.
• Minor: the tarball/release naming convention (apache-cassandra-<version>-...) is inherited unchanged from the existing pattern and still says "apache" even for the fork build. That's pre-existing behavior (not introduced here) and matches how the other 3 entries are named, so not something this PR needs to fix — just noting it's now slightly less accurate for a non-apache source.

Bugs/correctness

• None found. The JDK/base-image auto-mapping in resolve-build-plan.sh keys off base.version read from the checked-out fork's build.xml, not the stable_version label, so 6.0-rustyrazorblade-HEAD will correctly fall into the 6.0/trunk JDK-21 bucket as long as the fork's build.xml reports a 6.x version — consistent with the manual dispatch validation mentioned in the description.
• fail-fast: false is already set on the matrix, so a fork build failure won't block the 3 apache/cassandra builds from publishing.

Test coverage

• No unit test changes, which seems right — this PR doesn't touch resolve-build-plan.sh/resolve-ref.sh logic (where the actual unit tests live), just the matrix data and release-notes strings in the caller workflow.

Security

• No secrets/permissions changes; checkout of the fork repo uses the same public-checkout pattern already used for apache/cassandra, and GHCR publish permissions are unchanged.

Overall: looks good to merge as-is. The cassandra_versions.yaml wiring is the only thing I'd double check is intentionally deferred.

[claude]

Review

Small, well-scoped, self-documenting CI/config change. Confirmed the mechanics line up end-to-end:

• build-cassandra-ref.yml already accepts a repo input (default apache/cassandra) at both workflow_dispatch and workflow_call, so making repo explicit per matrix entry and wiring matrix.repo through is a clean use of an existing extension point, not new plumbing.
• install_cassandra.sh's branch dispatch (url/branch set, url not ending in .tar.gz → git-clone-and-ant-build path) matches the new 6.0-rustyrazorblade entry in cassandra_versions.yaml exactly, and mirrors the already-documented custom-build pattern in docs/user-guide/installing-cassandra.md:184-223. No parsing/branching bug here.
• resolve-build-plan.sh's JDK auto-map falls through to the * case (JDK 21, noble base) for a 6.0-based base.version, consistent with the java: "21" set in the packer entry.
• The nightly release body / Stable Download URLs bullet is generated from stable_version, which is correctly threaded through the aggregation job's rename step (cassandra-tarball-<stable_version> → apache-cassandra-<stable_version>-bin.tar.gz), so the new URL line will actually resolve once the workflow runs.
• Manual dispatch against the real fork branch (linked run) already validated the build + image + CQL smoke test, which is good evidence this isn't just YAML that looks right.

Two minor, non-blocking notes:

1. Naming overlap risk: the CI matrix produces 6.0-rustyrazorblade-HEAD (nightly tarball) while the packer entry is 6.0-rustyrazorblade (git-clone-at-bake-time, no -HEAD suffix). Both build from the same fork branch but via entirely different mechanisms (one fetches a pre-built nightly tarball, the other clones+compiles on the packer host). That's intentional per the PR description, but the near-identical names could confuse someone skimming cassandra_versions.yaml later without the PR context — a one-line comment above the new packer entry noting "distinct from the 6.0-rustyrazorblade-HEAD nightly build; this clones+builds instead" would save future confusion.
2. Docs table gap: docs/user-guide/installing-cassandra.md's "Supported Versions" table isn't updated with the new 6.0-rustyrazorblade packer entry. If this is meant to be usable via easy-db-lab cassandra use 6.0-rustyrazorblade today, it's worth a row (or an explicit note that it's fork/experimental-only for now). If it's intentionally left off pending the deferred AMI bake validation, ignore this.

No security, correctness, or test-coverage blockers — the packer YAML addition is data-only (no new code paths), and the workflow diff is additive to an already-tested, parameterized reusable workflow. The PR body's caveat that no AMI bake has been run yet is a fair and clearly-flagged limitation rather than a hidden risk.

[claude]

Review

Small, mostly mechanical PR (matrix wiring + docs), but I found one issue in the third commit that's worth resolving before the next AMI bake.

Likely build failure: git-clone AMI-bake path hardcodes JDK 11, but 6.0-line Cassandra needs 17+

packer/cassandra/cassandra_versions.yaml adds:

- version: "6.0-rustyrazorblade"
  java: "21"
  python: "3.11.9"
  url: "https://github.com/rustyrazorblade/cassandra.git"
  branch: "cassandra-6.0-rustyrazorblade"

This is the first entry in the repo's history with a .git url (confirmed via git log --follow -p on cassandra_versions.yaml — every prior entry either has no url, an official-Apache-prefix download, or a .tar.gz nightly URL). That means it's the first entry to actually exercise the git-clone-and-ant-build branch of install_cassandra_version() in packer/cassandra/install/install_cassandra.sh (~lines 228-243):

local ANT_FLAGS
ANT_FLAGS=$(yq '.[] | select(.version == env(version)) | .ant_flags // ""' "$YAML")
# all builds work with JDK 11 for now
...
ant realclean >"$ant_log" 2>&1 && ant -Dno-checkstyle=true $ANT_FLAGS >>"$ant_log" 2>&1 || exit 1

The per-version java field is never read in this function — the whole script builds under whatever JDK update-java-alternatives set globally earlier (line 116: hardcoded to Java 11), and the comment says "all builds work with JDK 11 for now." That was true for every entry that previously existed (4.0/4.1 go through the official-download path, not git-build), so it never actually mattered in practice until now.

This repo's own resolve-build-plan.sh (used by the GitHub Actions nightly engine, and unit-tested) explicitly documents that 6.0/trunk need JDK 21 to build:

5.0*) auto_jdk=17; ...
*)    auto_jdk=21; ...   # 5.1+/trunk

and the new cassandra_versions.yaml entry itself declares java: "21". But that java field only affects runtime JDK selection (UseCassandra.kt → set-java-version), not the AMI-bake-time ant build. So when easy-db-lab build-cassandra runs, this fork will be compiled with ant under JDK 11 despite needing 17+, which will most likely fail the build (or at best silently miscompile).

There's also a java_build field already defined on CassandraVersion (configuration/CassandraVersion.kt:37-38, JSON property java_build) that looks like it was meant for exactly this, but it's never read anywhere else in the codebase — dead/vestigial today. Might be worth wiring install_cassandra.sh's git-build branch to switch JDK (via update-java-alternatives -s or a per-build JAVA_HOME override) using either java_build or the existing java field before invoking ant, keyed off the version's declared JDK rather than the process-global default.

The PR description acknowledges this gap ("Validated structurally only... No AMI bake was run"), and there's no automated coverage that would catch it — testPackerCassandra only runs prepare_instance.sh + install_cassandra_easy_stress.sh, not install_cassandra.sh, so the git-build path isn't exercised in CI either. Worth running an actual easy-db-lab build-cassandra against this branch before merging, or at minimum flagging this as a known-untested risk.

Minor / worth confirming intent

docs/user-guide/installing-cassandra.md's own "Custom Builds" section (pre-existing, not touched by this PR) says: "You don't edit the repository's cassandra_versions.yaml. Instead, drop... YAML files into your profile's extras directory" — specifically for personal-fork use cases like this one. This PR does the opposite: it commits the personal fork directly into the shared, built-in cassandra_versions.yaml, so every easy-db-lab build-cassandra run for every user now clones and builds rustyrazorblade/cassandra by default. If that's intentional (baking it in for everyone rather than keeping it as a personal extras entry), that's fine — just flagging the inconsistency with the documented pattern in case it wasn't deliberate.

Everything else looks solid

• The GH Actions matrix changes are clean: repo was already a first-class input on the reusable build-cassandra-ref.yml workflow (defaulting to apache/cassandra), so wiring matrix.repo through is low-risk, and it was validated end-to-end per the PR description (linked successful workflow run building the fork directly).
• Making repo explicit on all matrix entries is a nice self-documentation improvement now that the source isn't always apache/cassandra.
• CassandraVersion treats version as an opaque string everywhere (dedup, sorting, display), so adding a version string with extra hyphens (6.0-rustyrazorblade) doesn't risk breaking any parsing/sorting logic.
• Docs updates (commands.md, tutorial.md, installing-cassandra.md) are consistent with each other and correctly positioned relative to 6.0-HEAD.

[claude]

Review

Overall this is a clean, well-scoped CI/config/docs change (making repo: explicit in the nightly build matrix, adding the fork as a 4th entry, and wiring the fork into the packer AMI-bake path). The .github/workflows/build-cassandra-ref.yml reusable engine already supported a repo: input with an apache/cassandra default, so the matrix wiring in commit 1 is low-risk and well-documented. One real issue in commit 2 worth fixing before merge:

1. packer/cassandra/cassandra_versions.yaml: the new entry is pinned to a frozen, one-off build, not the tracked nightly

- version: "6.0-rustyrazorblade"
  url: https://github.com/rustyrazorblade/easy-db-lab/releases/download/cassandra-6.0-alpha2-8c88f0159960/apache-cassandra-6.0-alpha2-8c88f0159960-bin.tar.gz

That release tag (cassandra-<version>-<short_sha>) matches exactly the per-sha release_tag format produced by resolve-build-plan.sh's compute_build_plan() — i.e. this URL is the artifact from the one manual workflow_dispatch run mentioned in the PR description (run 30406460393), not the moving nightly release tag that 5.0-HEAD, 6.0-HEAD, and trunk all point to (.../releases/download/nightly/apache-cassandra-<version>-bin.tar.gz).

Since commit 1 of this same PR adds 6.0-rustyrazorblade-HEAD to the nightly cron matrix (which will keep republishing a fresh tarball to the nightly tag every day), the AMI-bake path added in commit 2 doesn't actually consume that nightly artifact. It will forever install the exact commit that existed when the fork was manually tested on 2026-07-28, never picking up new commits pushed to cassandra-6.0-rustyrazorblade unless someone manually re-pins the URL again. That's inconsistent with how the other -HEAD entries behave, and with the "Nightly build from ... branch" framing used for 6.0-HEAD/5.0-HEAD in docs/user-guide/installing-cassandra.md (the new 6.0-rustyrazorblade doc row doesn't call out that it's frozen, so a reader could reasonably assume it tracks the branch like the neighboring rows do).

If tracking the branch was intended, this should point at .../releases/download/nightly/apache-cassandra-6.0-rustyrazorblade-HEAD-bin.tar.gz instead. If pinning was intentional (e.g. distrust of unreviewed nightly fork builds), that's a reasonable call, but worth stating explicitly in the docs table/PR description rather than leaving it implicit.

2. PR description says this enables a git-clone+ant build; the code doesn't do that

The commit message / PR body says the new entry lets install_cassandra.sh "git-clone and ant-build this branch directly." Looking at install_cassandra_version() in packer/cassandra/install/install_cassandra.sh, the git-clone/ant-build path only triggers when there's a branch: field and a non-.tar.gz URL (the trailing else branch, around line 228). Since the new entry only sets url: and it ends in .tar.gz, it actually takes the plain tarball-download branch (around line 180), same as 6.0-HEAD/trunk/5.0-HEAD. No branch: field is added anywhere in this diff. Worth correcting the description so future readers don't assume there's a source-build mechanism here — there isn't; this is a tarball download like its siblings.

3. Minor: new packer entry wasn't exercised by the existing packer test harness

The PR description says this was "Validated structurally only (YAML parses ...). No AMI bake was run." The repo already has ./gradlew testPackerCassandra for exactly this: running install_cassandra.sh in Docker against cassandra_versions.yaml without a full AWS build. Given the URL pinning issue above, running that target (or at minimum checking the tarball URL responds) before merge would catch both a dead/wrong URL and any future accidental invalidation of that pinned release.

4. Minor: nightly matrix now builds from a second repo under secrets: inherit

Not a blocker since rustyrazorblade/cassandra is the same owner's personal fork, but worth noting: the nightly cron job now checks out and builds a second repository with secrets: inherit (GHCR push + release write). Any future push to cassandra-6.0-rustyrazorblade — by anyone with write access to that fork — triggers a build using this repo's credentials. Fine as-is, just flagging the slightly widened trust boundary for awareness.

Nits

• Docs/matrix changes are internally consistent (docs/reference/commands.md, tutorial.md, and installing-cassandra.md all list 6.0-rustyrazorblade in the same place), and the repo: explicitness change to the matrix is a nice self-documentation improvement independent of the fork addition.