ci: the consumer path from the published package - #8
Merged
Conversation
The README said "v1.1.0 is current" while the newest tag was v1.1.2, and two paragraphs above it correctly stated the library version as 1.1.2. It now points at the releases page, which is always right, and says why pinning a tag matters: a release states a format version, and two endpoints interoperate only when they carry the same one. The distribution claim above it was checked against Maven Central and is accurate as written: no artifact under any coordinate. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Item six of the production bar: a real consumer path for every distribution claim.
What is published
Nothing. Checked against Maven Central directly:
a:serializeorg.mvnpm.at.keyv:serializeand friends)g:io.github.mas-bandwidthg:com.mas-bandwidth,g:com.masbandwidthmas-bandwidthThe README's "Getting it" section already said there is no artifact under any coordinate and no Maven or Gradle build here to produce one. Both halves are accurate: the repository builds with a plain Makefile over a pinned JDK, and
find . -name pom.xml -o -name 'build.gradle*'returns nothing.So there is no consumer job here
A consumer job installs a released version from an index and round trips a message through it. With nothing on Maven Central there is nothing to install, and a job that skips itself is not a gate. serialize.go, serialize.rs and serialize (C++) get one in their own PRs, because those three have a published artifact.
What changes instead
One sentence. The README said "v1.1.0 is current" while the newest tag is v1.1.2, and two paragraphs above it correctly said "Version 1.1.2 (
SerializeUtil.VERSION)", so the page disagreed with itself. Naming a version in that closing line means editing it by hand at every release, so it now points at the releases page and cannot go stale. It also says why pinning matters, which the bare version number did not: a release states a format version, and two endpoints interoperate only when they carry the same one.When an artifact is published
This port already exports the constant a consumer job would check:
SerializeUtil.VERSION, currently1.1.2. Add aconsumerjob matching the one in serialize (C++), which checksSERIALIZE_VERSIONfrom the installed header the same way: resolve the coordinate from Maven Central, build a fresh project outside the checkout against the released jar, encode the family's three field message (a boolean, an int in[0,1000], a 16 bit unsigned), check the bytes against121 149 132 0(verified against the published Rust crate and the published Go module), compareSerializeUtil.VERSIONin the jar against this repository, and fail on drift naming both versions.