Skip to content

fix(ci): make publishing-check resolve only what was just published - #110

Merged
projectdelta6 merged 1 commit into
mainfrom
bugfix/publishing-check-resolves-only-local
Aug 21, 2026
Merged

projectdelta6 merged 1 commit into
mainfrom
bugfix/publishing-check-resolves-only-local

Conversation

@projectdelta6

Copy link
Copy Markdown
Collaborator

The hole

publishing-check/settings.gradle.kts listed jitpack.io alongside mavenLocal(). The job's entire purpose is to verify what the toolbox just published locally — but with a remote repository in the list, a module that silently failed to publish could resolve from the released artifact of the same version and the check would pass having tested something else.

Latent when the job was written (nothing was released at 1.8.3 yet). Live the moment 1.8.3 was tagged.

Demonstrated, not assumed

MockInterceptor 1.8.3 deleted from ~/.m2, both shapes run:

with jitpack.io:     PASS x4, "resolves cleanly"          <- false green
without jitpack.io:  FAILED, could not find MockInterceptor:1.8.3

The first is the worse kind of failure: not a missing assertion, but a green actively certifying the released artifact as if it were this build's output.

Nothing needed the fallback — toolbox modules come from mavenLocal, third-party dependencies from google/mavenCentral — so the check still passes with it removed, and the negative control from the original commit still behaves (GMM disabled → okhttp-jvm / flexilogger-jvm flagged with the floors green).

Provenance

Found because the AssistantHood session withdrew a cache-provenance assertion in its own script — ~/.gradle/caches/modules-2 being machine-wide, it cannot attribute a fetch to a project — and flagged that the same ambiguity would apply to any CI reusing it. That prompted checking whether this job had an equivalent flaw. It did, of a different kind.

The recurring shape across this release: a fallback, cached or absent state lets a check succeed for a reason unrelated to what it claims to measure. Five instances turned up during 1.8.3, every one found by someone questioning their own evidence rather than by the check failing.

🤖 Generated with Claude Code

The check listed jitpack.io alongside mavenLocal. Now that 1.8.3 is released,
a module that silently failed to publish locally could resolve from the
released artifact of the same version instead — so the check would pass
having tested the wrong artifact entirely.

Demonstrated rather than assumed, by deleting MockInterceptor 1.8.3 from
~/.m2 and running both shapes:

  with jitpack.io:     PASS x4, "resolves cleanly"   <- false green
  without jitpack.io:  FAILED, could not find MockInterceptor:1.8.3

Nothing needed the fallback: the toolbox's own modules come from mavenLocal
and every third-party dependency resolves from google or mavenCentral, so
the check still passes with it removed.

Found via the AssistantHood session withdrawing a cache-provenance assertion
of its own. The general shape is the one that keeps recurring in this work: a
fallback or cached route lets a check succeed for a reason unrelated to what
it claims to measure. Here it was worse than a missing assertion, because a
green would have actively certified the released artifact as if it were the
build's output.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@projectdelta6
projectdelta6 merged commit 31e66b9 into main Aug 21, 2026
1 check passed
@projectdelta6
projectdelta6 deleted the bugfix/publishing-check-resolves-only-local branch August 21, 2026 14:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant