Skip to content

sync-lockfiles: every dependant keeps its manifest at the toplevel - #466

Closed
milyin wants to merge 1 commit into
mainfrom
drop-crate-path
Closed

sync-lockfiles: every dependant keeps its manifest at the toplevel#466
milyin wants to merge 1 commit into
mainfrom
drop-crate-path

Conversation

@milyin

@milyin milyin commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

The crate-path step exists for exactly two repositories — zenoh-java and
zenoh-kotlin, whose Cargo manifest lived under zenoh-jni/. Both are being
rebuilt on the generated zenoh-flat-jni bindings (eclipse-zenoh/zenoh-java#482,
eclipse-zenoh/zenoh-kotlin#669) and no longer contain that crate at all.

They are not leaving this workflow, though. What each keeps is a manifest at the
repository root, whose lockfile records the zenoh-flat-jni commit its CI
builds against:

# zenoh-kotlin/Cargo.toml — compiles to nothing anyone ships
[dependencies]
zenoh-flat-jni = { git = "https://github.com/eclipse-zenoh/zenoh-flat-jni.git", branch = "main" }
Cargo.lock:  source = "git+https://github.com/eclipse-zenoh/zenoh-flat-jni.git?branch=main#<40-hex commit>"

That is the pin their CI reads, and this workflow already knows how to move it:
overwrite the lockfile with zenoh's — which carries no zenoh-flat-jni entry, so
the pin is removed — rectify by resolving again, which writes back the current
commit and compiles it. Same sync, same auto-merging pull request, no special
casing. Rehearsed against the real zenoh lockfile before proposing this: the
rectify step compiled clean in under a minute and the pin came back pointing at
zenoh-flat-jni's main tip.

With no dependant left below the toplevel, the step, its if and the three
interpolations of its output all go. zenoh-c's build-resources/opaque-types
steps are unaffected — they always named their manifest explicitly.

Ordering

Merge after both SDKs have their root manifest on the branch this workflow
syncs
, i.e. their default branch:

root manifest on main?
zenoh-kotlin eclipse-zenoh/zenoh-kotlin#700, open, CI green
zenoh-java after eclipse-zenoh/zenoh-java#482 lands, with the same crate

Until then zenoh-java still keeps its manifest under zenoh-jni/, and this would
point its sync at a path that does not exist. Unrelated to #465,
which only adds zenoh-flat and zenoh-flat-jni to the matrix and can merge
whenever.

The crate-path step existed for zenoh-java and zenoh-kotlin alone, whose
Cargo manifest lived under zenoh-jni/. Both SDKs are being rebuilt on the
generated zenoh-flat-jni bindings and no longer contain that crate; what
they keep is a manifest at the repository root, whose lockfile records
the zenoh-flat-jni commit their CI builds against - so this workflow
moves that pin for them exactly as it moves everyone else's.

With no dependant left below the toplevel, the step, its `if` and the
three interpolations of its output all go. zenoh-c's build-resources
steps are unaffected: they always named their manifest explicitly.
@milyin

milyin commented Aug 10, 2026

Copy link
Copy Markdown
Contributor Author

Folded into #465, which now carries both the new matrix entries and this crate-path removal — one PR for the whole zenoh-java/zenoh-kotlin change to this workflow. Branch drop-crate-path left in place; the commit is cherry-picked onto sync-lockfiles-zenoh-flat unchanged.

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