DIY Dockerfile.repo not honoring cargo locks results in non-deterministic builds#8983
DIY Dockerfile.repo not honoring cargo locks results in non-deterministic builds#8983theJC wants to merge 3 commits intoapollographql:devfrom
Conversation
…ndeterministic build results
✅ AI Style Review — No Changes DetectedNo MDX files were changed in this pull request. Review Log: View detailed log
|
theJC
changed the title
… align with ci build
| # Build and install the router | ||
| RUN cargo install --path apollo-router | ||
| # Build the router | ||
| RUN cargo build --release -p apollo-router |
There was a problem hiding this comment.
This is what the ci build uses, lets use this which honors the lockfile and so the DIY more closely aligns to the ci build.
| COPY . . | ||
|
|
||
| # Build and install the router | ||
| RUN cargo install --path apollo-router |
There was a problem hiding this comment.
because this didnt have --locked it was not honoring the cargo lock, and builds of an identical hash could end up with a different version of libraries.
| RUN mkdir -p /dist/config && \ | ||
| mkdir /dist/schema && \ | ||
| mv /usr/local/cargo/bin/router /dist | ||
| mv target/release/router /dist |
There was a problem hiding this comment.
since we are building and not installing now
theJC
changed the title
|
@mergify copy dev |
✅ Pull request copies have been createdDetails
|
|
Nice fine. We really need to fix the contributor PR path. I'll get this over the line, again, for now, but making the copy at #8988 so I can fast-track it. |
|
#8988 has landed. thanks! |
2 participants
DIY Dockerfile.repo is not honoring cargo locks results in non-deterministic builds
I used it and ended up with a binary that had newer version of the h2 library than the official build, this change will fix the problem.
Checklist
Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.
Exceptions
Note any exceptions here
Notes
Footnotes
It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩
Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩
A lot of (if not most) features benefit from built-in observability and
debug-level logs. Please read this guidance on metrics best-practices. ↩Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩