CI: pin third-party actions, fix the triggers, drop both nightlies by milyin · Pull Request #526 · eclipse-zenoh/zenoh-java

milyin · 2026-08-11T22:50:16Z

What this is

zenoh-flat-jni#36 did
two things: it added a snapshot publication from main, and it applied
@diogomatsubara's review of that repository's CI. This repository already has
the publication half — snapshot from main, a ci status-check job, rustup show instead of a toolchain action. What it does not have is the review half,
which is this PR.

Three concrete defects, one commit each for the first two.

1. Every third-party action was on a mutable major tag

@v4, @v3, @v18 across four workflows. A tag is mutable, so a moved tag
runs code nobody reviewed — on jobs that hold the organization GPG key and the
Central token. Every third-party uses: now names a commit, with the version in
a trailing comment. eclipse-zenoh/* actions are ours and stay on a branch,
deliberately.

The pins are the same commits zenoh-flat-jni landed, so both halves of a
release run the same action code:

action	pin
`actions/checkout`	`3d3c42e` # v7.0.1
`actions/setup-java`	`b6effb0` # v5.7.0
`gradle/actions/setup-gradle`	`0723195` # v5.0.2
`actions/upload-artifact`	`043fb46` # v7.0.1
`peaceiris/actions-gh-pages`	`84c30a8` # v4.1.0
`DavidAnson/markdownlint-cli2-action`	`eb5ca3a` # v18

Two of those are bumps, each with its reason in place:

peaceiris/actions-gh-pages v3 → v4.1.0 — v3 runs on node16, a
runtime the Actions runner has retired. Inputs unchanged (github_token,
publish_dir).
setup-gradle v4 → v5, not v6 — v6 moved caching into a proprietary
component under Gradle's own terms of use, which is not ours to accept for an
Eclipse project. Same call as Remove zenoh-jni Debian package #36.

markdownlint-cli2-action is pinned where it stands, at v18. It is on
node20, which is not retired, and a newer major changes markdownlint's rules —
that is an upgrade to make on its own, with whatever README edits it asks for,
not inside a pinning change.

checkout/setup-java/upload-artifact land on current majors as a
consequence of pinning to those commits. Checked before pinning: every input
these workflows pass still exists in the pinned version, and checkout still
defaults persist-credentials to true — ci/scripts/bump-and-tag.bash pushes
the release branch and tag with those credentials.

2. Every branch ran CI twice, and a nightly rebuilt what the last merge built

push and pull_request were both on ["**"], so one commit on a branch with
an open PR meant two full runs on two runners, and two entries in the checks
list. The block now follows the main zenoh repository, and the weekday nightly
goes with it:

push:
  branches: ["main", "release/*", "!release/dry-run/*"]
pull_request:
  branches: ["**"]
workflow_dispatch:

release/* is where a release is actually built from — the shared
create-release-branch action creates it — and the throwaway dry-run branches
that same action produces are excluded. Nothing loses coverage: a branch under
review is covered by pull_request, and a branch that is not under review had
no reader for its result. This PR's own checks tab is the demonstration —
one run, not two.

The nightly is dropped. The obvious argument for it is that it would catch
zenoh-flat-jni moving under us, and it does not — Cargo.lock pins that
dependency to a commit:

source = "git+https://github.com/eclipse-zenoh/zenoh-flat-jni.git?branch=main#<sha>"

and Cargo re-resolves a git dependency only on cargo update or a missing lock
entry, so a timed build rebuilds exactly what the last merge built. Upstream
drift reaches this repository as a lockfile-sync pull request, which runs CI like
anything else. What a nightly would still catch is an expired Central token or
GPG key, and only during a week with no merges at all — every merge already
exercises them. That is a thin canary against a daily publication of two
coordinates, and under #525 it also risks a half-hour zenoh-flat-jni rebuild for
no new commit. workflow_dispatch still runs the path on demand.

This is the same call zenoh-flat-jni#36 made and recorded in its PUBLISHING.md;
that PR's description says the other JVM repositories keep their nightly, which
this makes stale — only zenoh-kotlin does now. Corrected there.

3. `release.yml` ran a dry-run release every night, and it failed every night

Its own separate 0 0 * * 1-5. A scheduled run passes no inputs, so it passes no
zenoh-flat-jni-version, so it fell back to zenohFlatJniVersion in
gradle.properties — a version not on Maven Central — and died compiling:

Could not find org.eclipse.zenoh:zenoh-flat-jni:1.9.0

PUBLISHING.md documented that failure rather than treating the schedule as the
mistake. The workflow is now workflow_dispatch only. Nothing is lost: a dry run
rehearses the release path, and rehearsing is as deliberate an act as the release
it rehearses — both are Actions → Release → Run workflow, with the version in
the box.

4. `PUBLISHING.md` did not say the actions were pinned

One paragraph under How the pipeline works, so the next person to bump one
knows it is a reviewed change rather than a version-number edit. The paragraph
that explained why the nightly release run always failed is rewritten too — that
run is gone.

Deliberately not in scope

From #36	Why not
snapshot publish from `main`, `ci` status job, `rustup show`	already on `main` here
`concurrency`	#525 adds it, stacked on this branch, with `cancel-in-progress: false` — it publishes two coordinates from two uploads, and cancelling between them is the failure it must avoid.
the `release.yml` nightly dry-run release	a different schedule and a different mechanism; dropping it is its own call
`Swatinem/rust-cache`	no cargo step here. Gradle drives cargo inside `.zenoh-flat-jni/`, fetched during the build, so there is no `Cargo.lock` at restore time to key a cache on. `setup-gradle` already caches what this job reuses.

Verification

No third-party action left on a tag:

$ git grep -n "uses:" -- .github/workflows | grep -v "eclipse-zenoh/" | grep -v "\./\.github" | grep -v " # v"
$

Each pin re-resolved against the API, annotated tags dereferenced — all six
match the trailing comment.
All six workflow files still parse.
setup-gradle v5 and the pinned checkout/setup-java/markdownlint are
exercised by this PR's own run. actions-gh-pages v4 is reachable only from a
release, so it wants a dry-run release (live-run: false) before the next
real one: the deploy step is gated on live-run, so the rehearsal proves the
action resolves without touching gh-pages.

Relationship to #525

#525 is now stacked on this branch — its base is ci/pin-actions, so this
one merges first and GitHub retargets it to main automatically. Same shape as
zenoh-flat-jni#36/#37. The rebase is done: #525 pins the four steps it adds
(flat_jni_pin's checkout, and consumer_test's checkout / setup-java /
setup-gradle), so main gets nothing unpinned, and it rewrites the three
sentences that described the nightly.

concurrency still belongs to that branch, with cancel-in-progress: false —
its pair of uploads must not be cancelled between them.

@diogomatsubara

zenoh-flat-jni#36 applied this rule there, from @diogomatsubara's review, and this repository is the other half of the same release: a tag is mutable, so a moved tag runs code nobody reviewed - on jobs that hold the organization GPG key and the Central token. Every third-party `uses:` across the four workflows now names a commit, with the version in a trailing comment. Actions under eclipse-zenoh/ are ours and stay on a branch, deliberately. The pins are the same commits zenoh-flat-jni landed, so the two repositories run the same action code. Two of them are also bumps, and each says why in place: - peaceiris/actions-gh-pages v3 -> v4.1.0. v3 runs on node16, a runtime the Actions runner has retired. Its inputs are unchanged. - gradle/actions/setup-gradle v4 -> v5, not v6: v6 moved caching into a proprietary component under Gradle's own terms of use, which is not ours to accept for an Eclipse project. markdownlint-cli2-action is pinned where it stands, at v18. It is on node20, which is not retired, and a newer major changes markdownlint's rules - that is an upgrade to make on its own, with whatever README edits it asks for, not inside a pinning change. checkout, setup-java and upload-artifact land on current majors as a consequence of pinning to those commits. Every input these workflows pass still exists in the pinned versions, and checkout still defaults persist-credentials to true, which the release branch push in ci/scripts/bump-and-tag.bash depends on.

Three things in the `on:` block, following the main zenoh repository as zenoh-flat-jni#36 did. `push` and `pull_request` were both on `["**"]`, so every push to a branch with an open pull request ran the whole job set twice - two builds on two runners for one commit, and two entries in the checks list to read. `push` now covers main and `release/*`, minus the dry-run branches. A release is built from a branch the shared create-release-branch action creates, and CI has never run on it - `push: ["**"]` did cover that, but only as a side effect of covering everything. `pull_request` stays on every branch, so a backport targeting a release branch still gets CI, and nothing loses coverage: a branch under review is covered there, and a branch that is not under review had no reader for its result. The weekday nightly goes. The obvious argument for it is that it would catch zenoh-flat-jni moving under us, and it does not: Cargo.lock pins that dependency to a commit, source = "git+https://github.com/eclipse-zenoh/zenoh-flat-jni.git?branch=main#<sha>" and Cargo re-resolves a git dependency only on `cargo update` or a missing lock entry, so a timed build rebuilds exactly what the last merge built. Upstream drift arrives here as a lockfile-sync pull request, which runs CI like anything else. What a nightly would still catch is an expired Central token or GPG key, and only during a week with no merges at all - every merge already exercises them. That is a thin canary against a daily publication of two coordinates, and under #525 it also risks a half-hour zenoh-flat-jni rebuild for no new commit. workflow_dispatch still runs the path on demand. zenoh-flat-jni#36 dropped its own nightly for the same reason and recorded it in PUBLISHING.md; its description said the other JVM repositories keep theirs, which this makes stale - only zenoh-kotlin does now. Concurrency is deliberately not touched here - #525 adds it, with cancel-in-progress false, because the pair of publications that branch introduces must not be cancelled between the two uploads.

release.yml ran on `0 0 * * 1-5` as well as on dispatch. A scheduled run passes no inputs, so it passes no `zenoh-flat-jni-version`, so it fell back to `zenohFlatJniVersion` in gradle.properties - a version not on Maven Central - and died while compiling. Every weeknight, for as long as that has been true. PUBLISHING.md documented the failure rather than the schedule being wrong. Nothing is lost by removing it. A dry-run release rehearses the release path, and rehearsing is a deliberate act with a version in the box, exactly like the release it rehearses. Actions -> Release -> Run workflow does both. Same reasoning as the CI nightly in the previous commit, one workflow over.

#526 removes both weekday schedules - CI's 06:00 snapshot run and release.yml's 00:00 dry run - so three sentences added here describe a trigger that will not exist: - the ci.yml comment above the publishing jobs, "every merge there plus the weekday nightly above"; - "every merge to `main` and the weekday nightly upload a mutable pre-release build"; - the rehearsal section, which offered the nightly release run as an example of leaving `zenoh-flat-jni-version` empty. The last one was the weakest of the three anyway: that run failed while compiling every night, because an empty input fell back to a version not on Maven Central. What this branch changes about it is the part worth saying - the fallback is now our own published copy, so an empty field is a sound default rather than a guaranteed failure. The crons themselves are left to #526; touching them here would only conflict.

#526 pins every third-party action in these workflows; the four steps added here - the checkout in flat_jni_pin, and the checkout, setup-java and setup-gradle in consumer_test - were written against the unpinned form and would land on main as the only tags left. Same commits, same trailing comments.

#526 removes both weekday schedules - CI's 06:00 snapshot run and release.yml's 00:00 dry run - so three sentences added here describe a trigger that will not exist: - the ci.yml comment above the publishing jobs, "every merge there plus the weekday nightly above"; - "every merge to `main` and the weekday nightly upload a mutable pre-release build"; - the rehearsal section, which offered the nightly release run as an example of leaving `zenoh-flat-jni-version` empty. The last one was the weakest of the three anyway: that run failed while compiling every night, because an empty input fell back to a version not on Maven Central. What this branch changes about it is the part worth saying - the fallback is now our own published copy, so an empty field is a sound default rather than a guaranteed failure. The crons themselves are left to #526; touching them here would only conflict.

#526 pins every third-party action in these workflows; the four steps added here - the checkout in flat_jni_pin, and the checkout, setup-java and setup-gradle in consumer_test - were written against the unpinned form and would land on main as the only tags left. Same commits, same trailing comments.

* CI: publish the zenoh-flat-jni the snapshot was built against The nightly snapshot publication has never got past compiling: it resolves `zenoh-flat-jni:1.9.0`, and nothing of zenoh-flat-jni has ever been published under any version. Naming its own `1.9.0-SNAPSHOT` instead would fix the symptom and break two things — this repository's CI would then wait on that repository's CI, and the coordinate always holds the tip of *its* main while we compile against the commit `Cargo.lock` pins. JNI being a binary contract, that mismatch surfaces as `UnsatisfiedLinkError` at runtime, not as a build failure. So the publication publishes what it depends on. On `main` — every merge plus the weekday nightly, as before — it builds zenoh-flat-jni from the pinned commit and uploads it as `1.9.0-java-SNAPSHOT`, then builds and uploads the SDK against that. Self-sufficient, because it uses that repository's *source at a commit we choose*, never an artifact its CI produced; coherent, because the dependency our POM names is what we compiled against. - `flat_jni_pin` reads the pin from `Cargo.lock` and the commit stamp from the three published coordinates. Rebuilding means ten cross-compiled targets and half an hour, and the pin moves about once a day, so it happens only when the published copy is not already that commit. Anything missing or unreadable reads as "not ours" and rebuilds. - `publish_flat_jni_copy` calls zenoh-flat-jni's own publication workflow rather than duplicating its build matrix. `uses:` cannot hold an expression, so the workflow file comes from its `main` and the pin goes in `branch:` — the coupling is to a file in that repository, never to a run of its CI. - `-java` keeps our copy from overwriting the one zenoh-flat-jni publishes or zenoh-kotlin's; the three can legitimately pin different commits at once. The name is fixed, so it is overwritten rather than accumulated. - `--refresh-dependencies` on both SDK invocations: Gradle caches changing modules for 24 hours and setup-gradle restores that cache, so without it the SDK could compile against yesterday's copy while publishing a POM naming the coordinate that now holds today's. - `ci/consumer-smoke-test` resolves the published snapshot from a clean build with no connection to this one and takes a key expression through JNI. That is the only check that the POM, the transitive dependency and the native library work for someone who is not us. - `bump-and-tag.bash` now checks the value `gradle.properties` ends up with: main inherits a snapshot, so *omitting* `zenoh-flat-jni-version` is how a release would reach one, which the input-only check did not cover. - CI runs on `main` are serialized rather than cancelled. Two uploads cannot be made atomic, and cancelling mid-publication is what splits them; PUBLISHING.md says so rather than claiming coherence by construction. The test job is untouched: it still builds zenoh-flat-jni from source through the composite build, which keeps that path from rotting. Verified end to end locally through Maven Local: the qualified copy publishes with its commit stamp, the SDK compiles and publishes against it, and an outside consumer resolves both and prints `zenoh-java smoke test OK`. Needs eclipse-zenoh/zenoh-flat-jni's `source-repository`/`version-qualifier` inputs on `main` first. * CI: tell zenoh-flat-jni which base version we expect Its coordinate comes from its own version.txt, ours from gradle.properties. A pin that moves past a version bump there would publish 1.10.0-java-SNAPSHOT while this SDK still resolves 1.9.0-java-SNAPSHOT — and only fail afterwards. flat-jni-copy.bash now emits the base version and ci.yml passes it as expected-base-version, so eclipse-zenoh/zenoh-flat-jni#37's preflight catches the mismatch before anything is built. * CI: publish the commit that triggered the run, and check the copy is whole Review of #525. - **The SDK publication was resolving `main`, not the run's commit.** Concurrency queues a newer run; it does not hold the branch still. So run A could read Cargo.lock at A, spend half an hour building the JNI copy from A's pin, and then publish SDK source B against it — recreating exactly the mismatch this job exists to prevent, and persisting if B's queued run later fails. It now passes `github.sha`. - **Three matching stamps were not proof of a finished publication.** The POM is uploaded before the Gradle module metadata and before the jar or aar, so a run that died in between would leave three readable stamps, no module metadata for a consumer to resolve a variant against, and a decision to skip rebuilding — permanently, since every later run reads the same three stamps. Nothing downstream would catch it: the consumer smoke test runs on Linux and the broken variant could be the Android one. The decision now also requires each coordinate's metadata to advertise `pom`, `module` and its binary (`jar`, or `aar` for Android), which is what a complete upload lists. Verified against the real 1.9.0-rc8-SNAPSHOT, and the two ways to be unfinished are in the self-test. - **PUBLISHING.md contradicted itself.** The rehearsal sections still said an empty `zenoh-flat-jni-version` falls back to an unreleased `1.9.0` and dies while compiling, and sent operators to zenoh-flat-jni's own rehearsal snapshot. The fallback is now our own `1.9.0-java-SNAPSHOT`, which resolves — what it cannot do is reach a live release, and it is `bump-and-tag.bash` that stops that. "No consumer test" was also listed as a known gap; the gap now is only that a *release* candidate is not consumable, being in staging. * CI: require the whole coordinate to be at one build, not merely present Review of #525. The presence check missed the case that matters more than a first publication: an overwrite that failed part-way. Every <snapshotVersion> in a snapshot's maven-metadata.xml carries its own <value>, updated as that file lands. After the first complete publication all three extensions are listed and stay listed, so an overwrite that replaced the POM and then failed leaves the POM at build N+1 with the module metadata and the binary still at N. The old check saw three extensions, read the N+1 POM, found the pin in its stamp, and skipped rebuilding — permanently, and with a coordinate split across two JNI builds. So the check is now agreement rather than presence: the unclassified pom, module and binary entries must all name the same <timestamp>-<buildNumber>, and the POM is fetched by that name, so a metadata entry pointing at a file that never landed reads as no stamp and rebuilds. `timestamped_name` became `snapshot_value`, since the build identifier rather than one file name is what is being compared. The self-test gains the split case, which the previous fixtures could not express. Checked against the published 1.9.0-rc8-SNAPSHOT: all three coordinates whole, at 1.9.0-rc8-20260810.012355-1. * docs: stop describing a nightly this repository no longer has #526 removes both weekday schedules - CI's 06:00 snapshot run and release.yml's 00:00 dry run - so three sentences added here describe a trigger that will not exist: - the ci.yml comment above the publishing jobs, "every merge there plus the weekday nightly above"; - "every merge to `main` and the weekday nightly upload a mutable pre-release build"; - the rehearsal section, which offered the nightly release run as an example of leaving `zenoh-flat-jni-version` empty. The last one was the weakest of the three anyway: that run failed while compiling every night, because an empty input fell back to a version not on Maven Central. What this branch changes about it is the part worth saying - the fallback is now our own published copy, so an empty field is a sound default rather than a guaranteed failure. The crons themselves are left to #526; touching them here would only conflict. * CI: pin the actions this branch adds #526 pins every third-party action in these workflows; the four steps added here - the checkout in flat_jni_pin, and the checkout, setup-java and setup-gradle in consumer_test - were written against the unpinned form and would land on main as the only tags left. Same commits, same trailing comments. * Repin zenoh-flat-jni at the commit that carries the publication inputs eclipse-zenoh/zenoh-flat-jni#37 is merged, so `publish.yml@main` now accepts `source-repository`, `version-qualifier` and `expected-base-version`, and every POM it publishes carries `zenoh.flatJniCommit`. The pin here was e75529c, which predates all of that: the preflight added by that PR rejects it by design, and the workflow this branch adds could not start at all while the inputs it names were not on main. Only the zenoh-flat-jni line moves. `cargo update -p zenoh-flat-jni --precise` also re-resolved the zenoh git dependencies to the tip of their branch, which this branch has no business carrying: zenoh-flat-jni@6b5c04c was tested against 773126fd, and the lockfile-sync bot is what moves that rev in step with Zenoh's own. They are pinned back, leaving a one-line diff.

* CI: pin third-party actions, fix the triggers, drop both nightlies The same three changes eclipse-zenoh/zenoh-java#526 made, for the same reasons. - Every third-party action pinned to a commit, version in a trailing comment. A tag is mutable, and these workflows hold the signing key and the Central token. eclipse-zenoh/* actions are ours and stay on a branch. Pinning also picked up stale majors: setup-java v4 -> v5.7.0, setup-gradle v4 -> v5.0.2, upload-artifact v4 -> v7.0.1, actions-gh-pages v3 -> v4.1.0. setup-gradle stops at v5: v6 moved caching into a proprietary component under Gradle's own terms of use, which is not ours to accept for an Eclipse project. - Triggers follow the main zenoh repository. `push` on main and release branches - a release is built from a branch create-release-branch makes, and CI never ran on it - and `pull_request` on every branch, so a backport against a release branch gets CI. Not `push` on every branch as well: with pull_request on, that ran the whole matrix twice per branch. - Both nightlies go. ci.yml's would have rebuilt exactly what the last merge built, because Cargo.lock pins zenoh-flat-jni to a commit and Cargo re-resolves a git dependency only on `cargo update` - upstream drift arrives as a lockfile-sync pull request instead. release.yml's was worse than useless: a scheduled run passes no inputs, so every night it resolved the unreleased fallback in gradle.properties and died compiling. Releases and rehearsals are both deliberate acts, and both are `Run workflow`. * CI: publish the zenoh-flat-jni the snapshot was built against Closes the zenoh-kotlin half of eclipse-zenoh/zenoh-java#524, the same way eclipse-zenoh/zenoh-java#525 closes the other. gradle.properties named `zenoh-flat-jni:1.9.0`, a version that exists in no form, so the snapshot publication died in compileKotlinJvm every time it ran. Naming zenoh-flat-jni's own `1.9.0-SNAPSHOT` instead would fix the symptom and break two things: this repository's CI would wait on that repository's CI, and that coordinate always holds the tip of *its* main while this SDK compiles against the commit Cargo.lock pins. JNI being a binary contract, the mismatch surfaces as UnsatisfiedLinkError at runtime rather than as a build failure. The rule instead: **the publication publishes what it depends on.** On main, on every merge, build zenoh-flat-jni from the pinned commit, upload it as 1.9.0-kotlin-SNAPSHOT, then build and upload the SDK against that. - `flat_jni_pin` reads the pin from Cargo.lock and the commit stamp from all three published coordinates. Rebuilding is ten cross-compiled targets and about half an hour, and the pin moves roughly once a day, so it happens only when the published copy is not already that commit. Anything missing or unreadable reads as "not ours" and rebuilds - the safe direction. - `publish_flat_jni_copy` calls zenoh-flat-jni's own publication workflow rather than duplicating its six-target/four-ABI matrix, which is how the two would drift. - `-kotlin` keeps our copy from overwriting the one zenoh-flat-jni publishes or zenoh-java's; the three can legitimately pin different commits at once. The name is fixed, so it is overwritten rather than accumulated. - `--refresh-dependencies` on both SDK invocations. Gradle caches changing modules for 24 hours and setup-gradle restores that cache, so without it a run could upload copy B, compile against cached copy A, and publish a POM naming the coordinate that now resolves to B. - `ci/consumer-smoke-test` - a separate Gradle build with no path, project or composite connection to this one. It resolves the published snapshot from the snapshot repository and takes a key expression through JNI. Kotlin rather than Java because KeyExpr.tryFrom returns a Result, which an inline value class makes awkward to call from Java. - `concurrency` with cancel-in-progress false. The two uploads are not atomic, and cancelling a run mid-publication is exactly what leaves them naming different commits. - The release guard in bump-and-tag.bash now checks the value gradle.properties ends up with rather than the workflow input, because main inherits a snapshot and omitting the input is how a release would reach one. The pin moves to 6b5c04c, eclipse-zenoh/zenoh-flat-jni#37's merge commit: the earlier e75529c predates the version-qualifier inputs and the commit stamp this depends on, and that repository's preflight rejects it by design. Only that line of Cargo.lock moves - `cargo update -p` also re-resolved the zenoh git dependencies to their branch tip, which is the lockfile-sync bot's job, so they are pinned back.

milyin added 2 commits August 12, 2026 00:49

milyin force-pushed the ci/pin-actions branch from 653fb3e to 9fd7586 Compare August 11, 2026 23:01

milyin changed the title ~~CI: pin third-party actions, and stop running every branch twice~~ CI: pin third-party actions, fix the triggers, drop the nightly Aug 11, 2026

milyin mentioned this pull request Aug 11, 2026

CI: publish a snapshot from main, same rule as the other JVM repos eclipse-zenoh/zenoh-flat-jni#36

Merged

milyin changed the title ~~CI: pin third-party actions, fix the triggers, drop the nightly~~ CI: pin third-party actions, fix the triggers, drop both nightlies Aug 11, 2026

milyin mentioned this pull request Aug 11, 2026

CI: publish the zenoh-flat-jni the snapshot was built against #525

Merged

milyin merged commit d03ad72 into main Aug 11, 2026
6 checks passed

milyin mentioned this pull request Aug 12, 2026

CI: publish the zenoh-flat-jni the snapshot was built against eclipse-zenoh/zenoh-kotlin#703

Merged

Navigation Menu

Uh oh!

CI: pin third-party actions, fix the triggers, drop both nightlies - #526

CI: pin third-party actions, fix the triggers, drop both nightlies#526
milyin merged 3 commits into
mainfrom
ci/pin-actions

milyin commented Aug 11, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

milyin commented Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this is

1. Every third-party action was on a mutable major tag

2. Every branch ran CI twice, and a nightly rebuilt what the last merge built

3. release.yml ran a dry-run release every night, and it failed every night

4. PUBLISHING.md did not say the actions were pinned

Deliberately not in scope

Verification

Relationship to #525

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

milyin commented Aug 11, 2026 •

edited

Loading

3. `release.yml` ran a dry-run release every night, and it failed every night

4. `PUBLISHING.md` did not say the actions were pinned