Pin libnostr-c to v0.2.1 - #161
Conversation
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (1)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughThe CI workflow, release workflow, and reproducible Docker build now use the pinned Changeslibnostr-c checkout pin
Estimated code review effort: 1 (Trivial) | ~3 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
libnostr-c cut v0.2.1, so the pin here is now eight commits behind a release rather than ahead of one. The scheduled drift job reports it:
Moves all three locations together, which the agreement rule requires:
Dockerfile.reproducible,ci.ymlandrelease.yml.No firmware release needed
src/nip17.cis the only shipped source that changed in that range, and this firmware does not use NIP-17. Everything else is CI, tests, docs and version manifests. v0.2.1 does carry a fail-closed fix for NIP-17 sealing on a failed RNG draw, which matters to library consumers but is not reachable from this image.The two fixes that do matter here, the ESP32 RNG reporting failure and the FreeRTOS task-create fix, were already in the previous pin and shipped in v0.2.2.
dependencies.lock
components/libnostr-cis a component directory, so libnostr-c's ownidf_component.ymlis part of the manifest hash recorded independencies.lock. v0.2.1 bumped that manifest from 0.2.0 to 0.2.1, so the hash moves with the pin and the lock has to move with it. Onlymanifest_hashchanges; no component version is re-resolved.The first push omitted it and the lock guard from #152 caught exactly that, which is the behavior it was added for. The committed lock is byte-identical to what CI computed, so
beforeandafternow agree.Verification
./scripts/check-dependency-pins.sh --strictpasses after the change and failed before it. Built clean and flashed to an M5Stack CoreS3: