sync-lockfiles: every dependant keeps its manifest at the toplevel - #466
Closed
milyin wants to merge 1 commit into
Closed
sync-lockfiles: every dependant keeps its manifest at the toplevel#466milyin wants to merge 1 commit into
milyin wants to merge 1 commit into
Conversation
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.
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 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The crate-path step exists for exactly two repositories — zenoh-java and
zenoh-kotlin, whose Cargo manifest lived under
zenoh-jni/. Both are beingrebuilt on the generated
zenoh-flat-jnibindings (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-jnicommit its CIbuilds against:
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-jnientry, sothe 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
maintip.With no dependant left below the toplevel, the step, its
ifand the threeinterpolations of its output all go. zenoh-c's
build-resources/opaque-typessteps 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:
main?Until then zenoh-java still keeps its manifest under
zenoh-jni/, and this wouldpoint its sync at a path that does not exist. Unrelated to #465,
which only adds
zenoh-flatandzenoh-flat-jnito the matrix and can mergewhenever.