Skip to content

ci(publish): publish the compiler plugin only when it changes - #5

Merged
lukmccall merged 1 commit into
mainfrom
ci/publish-compiler-plugin-only-when-changed
Oct 30, 2026
Merged

lukmccall merged 1 commit into
mainfrom
ci/publish-compiler-plugin-only-when-changed

Conversation

@lukmccall

@lukmccall lukmccall commented Oct 29, 2026 •

Copy link
Copy Markdown
Collaborator

Why

Maven Central now caps how many files an organization publishes per month, and every file counts: each artifact goes up with its .asc, .md5 and .sha1. A Kolibri release uploads about 288 files. 220 of them are the compiler plugin (11 Kotlin builds × jar/sources/javadoc/module/pom × 4). The plugin hasn't changed since 0.2.0, but 0.2.1 through 0.2.4 each uploaded it again.

What

  • A separate version for the compiler plugin. gradle/libs.versions.toml gets a compiler-plugin version, starting at 0.2.4 (what's on Central now). :compiler-plugin publishes as <compiler-plugin>-<kotlin>, and the Gradle plugin resolves that version through a new BuildConfig.KOTLIN_PLUGIN_VERSION, which replaces KOLIBRI_VERSION.
  • Each stage-compiler matrix entry checks Central before staging. It builds the jar, and scripts/compare-with-maven-central.sh compares its entries with the jar Central holds at the same coordinates:
    • not on Central yet: staged and uploaded as before;
    • same contents: skipped, with a notice annotation;
    • different contents: the release fails before anything is uploaded, because the plugin changed without a version bump.
  • The README explains that the compiler plugin's version can be older than the rest of Kolibri.

The comparison works because the build is reproducible. Rebuilding the plugin locally for every Kotlin release in gradle/kotlin-versions.txt gives jars identical, entry by entry, to the 0.2.4-* jars on Central.

Is an older plugin safe with a newer runtime?

The only mix a consumer can get is an older plugin with a newer runtime, and CI already tests that mix: the plugin built from the current source is what the runtime and JNI tests compile with. If that source builds the same bytes as the published plugin, the shipped pairing has been tested. A runtime change that needs a plugin change changes the plugin bytes, and the release then fails until compiler-plugin is bumped.

Releasing after this

  • Plugin unchanged: bump kolibri only. The release uploads 68 files.
  • Plugin changed: also set compiler-plugin to the new version. If you forget, the publish workflow fails and says so.

One known edge case: repo1 can take ~30 min to serve a new upload. A release right after one that bumped the plugin may not find it there yet and try to upload it again. Central rejects the duplicate and the deployment fails as a whole; re-running later fixes it.

Testing

  • Ran the new workflow step locally against Central for all 11 Kotlin releases: every one reports published (it would be skipped).
  • Exercised the unpublished, changed-without-bump and unreachable-repository cases with the same script in ci(publish): publish the compiler plugin only when it changes expo-modules-v2-android#45.
  • :gradle-plugin:build passes; the generated KOTLIN_PLUGIN_VERSION is 0.2.4.
  • The publish workflow itself has not run in Actions yet; the next release is its first real run.

🤖 Generated with Claude Code

The compiler plugin gets its own version in the catalog (`compiler-plugin`), which the Gradle
plugin resolves. Each publish matrix entry builds the plugin, compares it with the jar Maven Central
holds under that version, and skips the upload when the contents match. A plugin that changed without
a version bump fails the release before anything is uploaded.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@lukmccall
lukmccall merged commit 0f605aa into main Oct 30, 2026
12 of 13 checks passed
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