fix: replace cargo generate-lockfile with targeted Cargo.lock edits for Android build - #170
Conversation
…or Android build (codex 0.149.0) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017oSojxW9njDBs5WTt9pLGZ
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 095baa55c3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if new_dep in dep_names: | ||
| raise ValueError(f"dependency already present: {new_dep}") |
There was a problem hiding this comment.
Treat already-present dependencies as a no-op
When a supported upstream release already includes either Android dependency in Cargo.lock, this exception aborts the workflow even though the surrounding manifest patches explicitly treat existing dependencies as already applied. Because the workflow accepts future rust-v0.1xx releases and invokes this script unconditionally, upstreaming either fix will turn a valid lockfile into a build failure; return the unchanged lockfile when new_dep is already present while retaining the uniqueness and format checks.
Useful? React with 👍 / 👎.
Replaces the full cargo generate-lockfile re-resolve (which was drifting rama-* pins to versions requiring rustc 1.96.0, incompatible with the build environment's rustc 1.95.0) with a deterministic direct edit of exactly two Cargo.lock deltas: codex-http-client gains openssl-sys, codex-thread-store gains libc. Both insertions fail closed if the target package block is not found exactly once. Design reviewed and Go'd in G1/G2 (GPT-5.6-terra), including verification against the actual upstream rust-v0.149.0 Cargo.lock.