Fix all instances of using the network after the pull phase#373
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the Snapcraft build recipe to eliminate network access during the build phase (moving it into the pull phase instead), reducing flakiness on Launchpad (notably riscv64).
Changes:
- Vendor Rust crates during
override-pullforlibrsvgso builds can proceed without reaching out to the network later. - Disable
mm-common’s Mesonuse-networkoption and fetch the required doctag file duringoverride-pullinstead.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
6cb63a8 to
aab6688
Compare
sergio-costas
left a comment
sergio-costas
left a comment
There was a problem hiding this comment.
I like it, specially the change in mm-common.
That points to a successful build in which Do you have a link to the build with the changes hereby proposed? |
The build did succeed, but you can see cargo downloading crates during build:
Will be provided by github CI in a few |
nteodosio
left a comment
nteodosio
left a comment
There was a problem hiding this comment.
I see.
Once the build output confirms the fix, can you please add an inline comment?
This project builds with cargo but uses the meson plugin, so we don't get a local cargo registry by snapcraft for free. Instead, let's manually set up a vendoring so that crates are correctly only downloaded during pull. "cargo-1.82 update" doesn't actually help, maybe because the cargo version changes after rustup.
We cannot rely on the network being available in the build phase. Download the required file in the pull phase.
|
aab6688 to
2f13ade
Compare
This shall make the build less flaky in launchpad, for riscv64 particularly.
Proof that the previous cargo workaround wasn't working: https://launchpadlibrarian.net/865012403/buildlog_snap_ubuntu_noble_riscv64_gnome-46-2404-sdk_BUILDING.txt.gz