Skip to content

ci(publish): pin the runner to the libmongoc floor's ubuntu - #29

Merged
youndie merged 1 commit into
mainfrom
ci/pin-publish-runner
Oct 2, 2026
Merged

youndie merged 1 commit into
mainfrom
ci/pin-publish-runner

Conversation

@youndie

@youndie youndie commented Oct 2, 2026

Copy link
Copy Markdown
Owner

Why

Renovate (#17) moved publish.yml from ubuntu-24.04 to ubuntu-26.04 together with the actions majors. The runner label is not incidental here: mongkn-core/build.gradle.kts generates the cinterop .def with the library names it finds on the build host and bakes them into the klib's linkerOpts.

Checked in the stock images (apt-get install libmongoc-dev libbson-dev, then the names the resolver would see in /usr/lib/x86_64-linux-gnu):

image mongo-c-driver .so names link options in the klib
ubuntu:24.04 1.26.0 libmongoc-1.0.so, libbson-1.0.so -lmongoc-1.0 -lbson-1.0
ubuntu:26.04 2.2.2 libmongoc2.so, libbson2.so -lmongoc2 -lbson2

So the next publish from 26.04 would have produced a klib that no consumer on the supported floor (libmongoc 1.26, Ubuntu 24.04, M-81) can link. The downstream native images in use are all ubuntu:24.04 with libmongoc-1.0-0t64. No publish has run since #17 (the last publish run predates it), so nothing broken went out.

What

  • publish.yml: back to ubuntu-24.04, with the reason next to the label. The Linux leg of build.yml is already on 24.04, so what is published is again what is tested.
  • .github/renovate.json5: Ubuntu runner labels (github-runners / ubuntu) are disabled for Renovate. The harness preset automerges github-actions majors, and no pull-request check executes publish.yml, so a green PR said nothing about this label. Moving it is raising the floor, done by editing publish.yml, build.yml and M-81 together. Checked with a Renovate dry run (--platform=local --dry-run=lookup): with the rule the log says Dependency: ubuntu, is disabled; a control without it does not.
  • MONGKN_REPO_URL: it was read by the verification step only, while the upload went wherever sborka.snapshotRepository pointed, so setting the secret would have sent the check somewhere the artefact never went. One job-level value now feeds both: the upload as -Psborka.snapshotRepository, the check as its root; without the secret it is sborka's default, as before.
  • M-81, the research document's floor decision and CLAUDE.md: "2.x is not packaged anywhere" is corrected (Ubuntu 26.04 packages 2.2.2); the floor stays at 1.26.
  • ChangeStreamFlow KDoc (and the same claim in CollectionOps.watch): it said "four subscriptions" would stall the client; the default pool is DEFAULT_IO_THREADS = 32 since M-78, and the text now refers to the pool size instead of a number. Two test-side comments that still called four the default are corrected too.

Verification

  • actionlint clean on publish.yml; renovate-config-validator --strict passes.
  • The Kotlin changes are comments and one benchmark label; CI (build, both legs) is the build proof.
  • publish.yml itself is workflow_dispatch only and is not run by this PR.

Renovate (#17) moved publish.yml to ubuntu-26.04 with the actions majors.
Ubuntu 26.04 ships mongo-c-driver 2.2.2 as libmongoc2/libbson2, and the
cinterop .def is generated with the library names found on the build host,
so the next published klib would have demanded -lmongoc2 -lbson2 from every
consumer on the supported floor (libmongoc 1.26, Ubuntu 24.04, M-81). No
publish has run since #17.

The runner goes back to ubuntu-24.04 and Renovate no longer touches Ubuntu
runner labels: the next label is raising the floor, not a bump.

MONGKN_REPO_URL was read by the verification step only, so setting the
secret would have pointed the check away from where the upload went. One
job-level value now feeds both: the upload as -Psborka.snapshotRepository,
the check as its root.

The change-stream KDoc still said four threads; the default is 32 since
M-78. The same stale number is corrected in the two test-side comments.
@youndie
youndie merged commit 34145f2 into main Oct 2, 2026
2 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