Open cameel opened 1 year ago
I'd say we should generally prefer https://github.com/ethereum/solidity/issues/9720 over automating preparing the source archive.
As for Publishing binaries on the github release page.
we should check what permissions this requires (it's probably at least repo write) and actually also whether we can restrict current permissions (i.e. make it harder to just replace binaries on finalized past releases).
I'd say we should generally prefer #9720 over automating preparing the source archive.
Well, just running the script to build seems simple enough. Might be worth doing it first anyway, just to automate that fully.
As for
Publishing binaries on the github release page.
we should check what permissions this requires (it's probably at least repo write) and actually also whether we can restrict current permissions (i.e. make it harder to just replace binaries on finalized past releases).
We should probably do it in github actions and just use the default token. Then we can make all tokens readonly by default and use the permissions
keys in the action to explicitly only request that one permissions.
Is it possible to also add nixpkgs
to the release process?
e.g. Dapptools uses this release process https://github.com/dapphub/dapptools/blob/master/nix/make-solc-static.sh - the binaries need to be patched to include additional ELF information, this is also a requirement for solc to work with foundry if used via nix. see this note https://github.com/shazow/foundry.nix#nixos-caveat
I can open a new issue if needed.
edit: this effects foundry as well https://github.com/foundry-rs/foundry/issues/545
Any update on the nix related comment I have raised, I can get this issue done if you will consider a PR that I submit?
I'm also eager to have this addressed to unblock nixpkgs
support and am willing to assist in the effort.
@sambacha What exactly would that involve? Running that script to update solc-static-versions.nix
and making a PR or actually rebuilding the binary? Currently going through the whole release checklist already takes more than we'd like and we're looking for ways to reduce it. So I'd rather not add another manual step. However, we're already doing similar things in some cases (Homebrew) so if it could be automated from the start and not make the release longer, I guess it could be ok.
Maybe it would be enough for us to just trigger some CI job on your side when the release is published so that you can do whatever other steps are required on your side? For example we could have a job on our side that is triggered by the release
published
event that would ping your CI, e.g. via workflow_call
if you're using Gihub Actions. We'd accept a PR implementing that.
I can open a new issue if needed.
Yeah, I think it would be better to open a new issue to track this. This one is really about automating what we already have.
Thanks @cameel for replying, let me coordinate with a few other people that are interested in this. I will create a new issue for it.
Will get back to you later this weekend, early next week.
Cheers
@sambacha What exactly would that involve? Running that script to update
solc-static-versions.nix
and making a PR or actually rebuilding the binary? Currently going through the whole release checklist already takes more than we'd like and we're looking for ways to reduce it. So I'd rather not add another manual step. However, we're already doing similar things in some cases (Homebrew) so if it could be automated from the start and not make the release longer, I guess it could be ok.Maybe it would be enough for us to just trigger some CI job on your side when the release is published so that you can do whatever other steps are required on your side? For example we could have a job on our side that is triggered by the
release
published
event that would ping your CI, e.g. viaworkflow_call
if you're using Gihub Actions. We'd accept a PR implementing that.I can open a new issue if needed.
Yeah, I think it would be better to open a new issue to track this. This one is really about automating what we already have.
This will actually be easier now to accomplish, at least for NixOS
"Nix-LD-RS provides a shim layer that allows users to specify the necessary libraries for each executable and improves the user experience by allowing users to easily run binaries from third-party sources and proprietary software"
https://github.com/Mic92/nix-ld this will become the default for patching in the future, so any changes potentially would only be needed in the short run
There are multiple things we would like to automate in the release process to reduce the amount of error-prone manual steps on the release checklist. Here's what we could do:
Must have
c_release_binaries
(or a new dependent job) run theupdate
script and create a PR.workflow_dispatch
) and that workflow would pull them in.c_release_binaries
could check if a page for the new release exists. If it does, it would upload them.Nice to have
(unreleased)
with the current date next to the version at the top of the changelog.CMakeLists.txt