chore: revive and improve release automation#2266
Conversation
Co-authored-by: Steve Loeppky <biglep@filoz.org>
- Update release-check.yml to use 'cargo publish --workspace --dry-run' - Update releaser.yml to automate 'cargo publish --workspace' on merge - Update CONTRIBUTING.md to reflect the new automated process and remove outdated limitations
…-workflows # Conflicts: # CONTRIBUTING.md
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #2266 +/- ##
=======================================
Coverage 77.02% 77.02%
=======================================
Files 143 143
Lines 14187 14187
=======================================
Hits 10927 10927
Misses 3260 3260 🚀 New features to boost your workflow:
|
- Enable OIDC trusted publishing for crates.io (id-token: write) - Use --no-default-features for cargo publish to avoid OpenCL dependency - Update release documentation to reflect these changes
|
|
||
| permissions: | ||
| contents: write | ||
| id-token: write |
There was a problem hiding this comment.
We should verify that this workflow is listed as a trusted publisher in crates.io.
There was a problem hiding this comment.
I'd look but I can't find the crate settings even though I should be in the team that has publish access, crates.io teams is janky, maybe @hanabi1224 || @LesnyRumcajs has a clue
There was a problem hiding this comment.
Settings should be next to Security on crates.io ,however, I don't have the setting permission of fvm* crates either
There was a problem hiding this comment.
There was a problem hiding this comment.
I think:
- https://crates.io/crates/fvm_ipld_amt/settings
- https://crates.io/crates/fvm_ipld_hamt/settings
- https://crates.io/crates/fvm_ipld_kamt/settings
- https://crates.io/crates/fvm_ipld_car/settings
- https://crates.io/crates/fvm_ipld_blockstore/settings
- https://crates.io/crates/fvm_ipld_bitfield/settings
- https://crates.io/crates/fvm_ipld_encoding/settings
There was a problem hiding this comment.
I think:
- https://crates.io/crates/fvm_ipld_amt/settings
- https://crates.io/crates/fvm_ipld_hamt/settings
- https://crates.io/crates/fvm_ipld_kamt/settings
- https://crates.io/crates/fvm_ipld_car/settings
- https://crates.io/crates/fvm_ipld_blockstore/settings
- https://crates.io/crates/fvm_ipld_bitfield/settings
- https://crates.io/crates/fvm_ipld_encoding/settings
I did the same setup for those as well - my bad for missing those previously.
|
Added @LesnyRumcajs as another maintainer who may be able to get to looking at this sooner. |
|
I'm OOO until Tuesday, best bet is @hanabi1224 now, I guess! |
|
worth a try! wouldn't harm to push through a release or three this has to also work for v3 and v4 so I guess we'd backport it to there as well? |
Yes, I don't see why not. I would test it in the default branch first and then do the backport if everything works as expected. |
|
What are the next steps? Do we just need to try it out? |
|
Yes, I did the testing we can do without doing a proper release in #2267 |
|
@LesnyRumcajs or @hanabi1224 : is there an upcoming proper release we can try this out with to validate it? |
|
Ok, so it seems like:
|
|
@galargh Can you please help me understand why do we need two very similar workflows? I understand one is for checking the release and another for an actual release, but ideally there'd be just one with a |
| sudo apt-get update | ||
| sudo apt-get install --no-install-recommends --yes libhwloc-dev ocl-icd-opencl-dev |
There was a problem hiding this comment.
nit: it might make sense to wrap it with retry. At least in Forest we had some issues with 500s from canonical servers from time to time
uses: nick-fields/retry@v3
with:
timeout_minutes: 5
max_attempts: 3
command: |
sudo apt-get install -y <deps>
| name: Release Checker | ||
|
|
||
| on: | ||
| pull_request_target: |
There was a problem hiding this comment.
Do we have to use this one? I understand this works on forks but, to my understanding, there are some security considerations around it
Running untrusted code on the pull_request_target trigger may lead to security vulnerabilities. These vulnerabilities include cache poisoning and granting unintended access to write privileges or secrets. For more information, see Secure use reference in the GitHub Enterprise Cloud documentation, and Preventing pwn requests on the GitHub Security Lab website.
6 participants
This PR revives the release automation effort from #2027 with several key improvements:
release-check.ymlto usecargo publish --workspace --dry-run. This leverages Cargo 1.90+'s native multi-package publishing to correctly verify the entire dependency graph, solving the previous failure with interdependent crates.releaser.ymlto include acargo publish --workspacestep. This automates the final push to crates.io upon merge, ensuring crates are published in the correct order.RELEASE.mdto reflect the new automated process and cleaned upCONTRIBUTING.mdto match the current project structure.master, including the transition of release documentation to its own file.Test Plan
To verify these changes, we will perform a live test by simulating a multi-crate release:
galargh/releasebranch.fvm_shared,fvm, andfvm_sdksimultaneously inCargo.toml.release-checkworkflow triggers correctly.Dry-run publishstep (cargo publish --workspace --dry-run) passes.Checklist: