Release workflow

[AndWeHaveAPlan]

Automatically create tag and relese based on 'version' in cargo.toml, triggered on main branch only. Do nothing if tag and relese already exist
Example

Release artifacts:

• llvm-linux-emscripten.tar.gz
• llvm-linux-gnu.tar.gz
• resolc
• resolc.js
• resolc.wasm

Current issues:

• If build and upload fail, tag and release must be manualy deleted to trigger new build for the same tag
• No tests performed for release
• No Win and MacOS build

Next steps:

• Workflow refactoring
• Build other platforms

[xermicus]

Can we please test the release workflows in a fork of this repository?

[xermicus]

Note: The test failure is caused by a change in go-ethereum, I'm on it.

[AndWeHaveAPlan]

Can we please test the release workflows in a fork of this repository?

Ok, I've forked the repo to
https://github.com/paritytech/revive-worflow-test/actions/runs/13241577827

[AndWeHaveAPlan]

Works in fork

v0.1.0-dev.10 "release"

[athei]

Didn't we agree to have the LLVM release separate? Meaning it is triggered manually so that it doesn't have to be rebuild for every release.

[xermicus]

That was the idea at first, however not doing this simplifies the release process. It also eases changing LLVM compilation settings between releases.

[AndWeHaveAPlan]

Didn't we agree to have the LLVM release separate? Meaning it is triggered manually so that it doesn't have to be rebuild for every release.

This is more of a temporary solution and will change (if needed), especially with addition of the win/mac build. For now we use actions/cache with hashfiles(...) to avoid full rebuild

[athei]

I see. Thanks for clarifying.

[xermicus]

v0.1.0-dev.10 "release"

I just checked the linux binary, it isn't the statically linked MUSL build? Also the workflow does not indicate at all that it will be building against MUSL. For Linux we want the musl build (only). Easiest way is to use musl-cross, see the Dockerfile in this repository (you can essentially just build this image and then copy the bianry from a dummy container afterwards).

Note: The gnu LLVM is fine to release though. LLVM builds we want to release both: MUSL for reproducibility and GNU so that contributors with slow laptops don't have to wait for an hour.

[AndWeHaveAPlan]

I just checked the linux binary, it isn't the statically linked MUSL build?

It wasn't :(

> file target/release/resolc
target/release/resolc: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=284e9e31366c72a3ad12d1981b55caa116de5979, for GNU/Linux 3.2.0, not stripped

Now it is static (and llvm-musl now in artifacts)
fork release
fork workflow

> file resolc
resolc: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, not stripped

[athei]

A few notes. Not 100% sure but I think (@xermicus please confirm):

• We neither want nor need any gnu build. Please remove. Musl is portable and will run on any Linux
• The LLVM artifacts should not be released. It is statically linked into the the other artifacts and there is no reason for people to download them. If they are released at all it will be in a separate workflow just to be downloaded by this very workflow.

resolc: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, not stripped

I love it :)

[xermicus]

We neither want nor need any gnu build

Confirmed.

If they are released at all it will be in a separate workflow just to be downloaded by this very workflow.

Ok let's go this route (with a separate workflow and separate release tags just for LLVM) just like originally intended. I just remembered the cache is limited to 10GB, which will not allow caching it for all platforms.

[athei]

Will the rest I asked for also be removed?

[AndWeHaveAPlan]

Ok, lets summarize everything we have

Note: The gnu LLVM is fine to release though. LLVM builds we want to release both: MUSL for reproducibility and GNU so that contributors with slow laptops don't have to wait for an hour.

The LLVM artifacts should not be released. It is statically linked into the the other artifacts and there is no reason for people to download them. If they are released at all it will be in a separate workflow just to be downloaded by this very workflow.

So we need to release both LLVM, as mentioned here

• linux-gnu (?)
• macos-gnu
• windows-gnu
• emscripten
• musl

and revive

From The final goal is to have two workflows:

• build and publish LLVM as a separate tag and release (like llvm-*). Triggered manually
• build and publish revive as a "true" release (like v1.2.3). Triggered for main branch by version change in cargo.toml and use llvm from the latest llvm-* release

This is a 'step 1' - 'minimal' workflow, so we can have at least some form of release for now. The LLVM release workflow is in a separate pr, but there are problems with the win build

Does everyone agree with this, or do we have a different point of view?

---

So I propose next steps:

• Step 2: two separate releases, but only linux-musl for now
• Step 3: add macos
• Step 4: add windows

[athei]

So we need to release both LLVM, #93 (comment)

Can you scroll down a bit? Just the next post in this thread I wrote why this list of targets does not make sense. But to recap. We want those AND ONLY THOSE releases of the resolc binary:

linux-musl
macOS (universal)
windows-msvc
emscripten

So I propose next steps:

I propose you start by fixing the trivial suggestions I made here: #201 (review)

• Remove all gnu builds. Not only the artifact.
• Don't release any LLVM artifacts from this workflow.

I don't know how to express this in any simpler terms.

[athei]

Please let me know when I should give it another review. Let's merge it without mac und windows for now so we have at least that.

[KarimJedda]

@AndWeHaveAPlan can you please add a few more comments and address Alex's questions? Pushing changes is great, discussing & explaining them is even better! Thank you :)

[AndWeHaveAPlan]

fork example for current workflow

• without gnu
• without llvm artifacts
• with new resolc_web.js file

[mutantcornholio]

Just to sync discussions between parallel streams: LLVM artifacts will be released in separate tags (the part I'm working on), to later be reused in this release workflow, as well as in test workflow.
#207 (comment)
#207 (comment)

[athei]

Thanks this looks like what we want :)

My main grumble here was that it is unclear when the author is still working on it and when it is considered "done" from their point of view. So I can start reviewing.

[xermicus]

Looks like we are getting close, thanks!

Can you please update the RELEASE.md file to reflect how the release works with the new workflow?

[xermicus]

Should we cache the musl artifacts directly after building it? Otherwise it's either both musl and emscripten work and get cached or nothing gets cached.

[AndWeHaveAPlan]

ok, reordered

[xermicus]

Unfortunately it doesn't look like they version it properly with tags. Can you please change this to use the image digest? This gives us manual control and will avoid breaking the release workflow randomly.

[AndWeHaveAPlan]

ok, set @sha256:68b86bc7cb2867259e6b233415a665ff4469c28b57763e78c3bfea1c68091561, image used in fork workflow

[xermicus]

This is technically not required for builds.

However, executing a basic tests using the release build, like compiling a flipper contract, would be good. Can you please add such a test? It can be really simple, i.e. running resolc --bin crates/integration/contracts/flipper.sol, expecting the PVM magic bytes 50564d in the output and expecting a return value of 0. Same for the Wasm build. It's unlikely but should the release workflow for some reason produce defective artifacts, without the test, we will only find it out the annoying way.