Add release workflow for Github Actions

[pamaury]

This actions compiles the system emulator with the relevant options and creates an archive that contains this binary, as well as some OT relevant scripts to prepare OTP/flash images. The script uses the GitHub CLI to then create a release and publish the binary. This automatically tags the commit as well. GitHub takes care of creating an archive for the source code.

Here is an example of release created by this script.

[jwnrt]

This is great, thanks @pamaury. Looks all good to me.

We might want a comment in here or in some docs showing how to create a release, even if it's just linking to https://docs.github.com/en/actions/using-workflows/manually-running-a-workflow.

[jwnrt]

Tiny nit, feel free to skip

Suggested change

	echo "Usage: $0 /path/to/output/tarball /path/to/build/dir /path/to/src/dir"
	echo "Usage: $0 /path/to/output/tarball /path/to/build/dir /path/to/src/dir" >&2

[nbdd0121]

Instead of workflow trigger, would it make more sense to trigger release by tag creation?

[pamaury]

I have no strong opinion as long as it works. Note that gh release creates a tag automatically so it's really just a question of using the GitHub UI vs manually pushing a tagging. I personally think the UI option is more discoverable. Any opinion @rivos-eblot @jwnrt ?

[jwnrt]

My personal preference is using the GitHub UI, just because it feels more discoverable, intentional, and closer to where the release is created.

[rivos-eblot]

I have no strong opinion as long as it works. Note that gh release creates a tag automatically so it's really just a question of using the GitHub UI vs manually pushing a tagging. I personally think the UI option is more discoverable. Any opinion @rivos-eblot @jwnrt ?

Not really, but I think it would be nice to be able to trigger a build at will (UI ?) as I do not think we want to create a tag for every single PR. This one seems to target the generation of artefacts to run Opentitan tests with a QEMU binary and I have no opinion on how to trigger it. However I guess another workflow is required at some point to validate the QEMU build itself (along w/ clang-format etc.) (?)

[nbdd0121]

I believe if you create a new release on GitHub UI, then it'll also create a tag? The CI can then kick in and generate the binary for that release

[nbdd0121]

Here's some example workflow that I use in a personal project for automatic release workflow: https://github.com/nbdd0121/wsld/blob/master/.github/workflows/ci.yml

It builds the artifact for each push, and if it's a tag push then it also releases the binary.

[pamaury]

Yes a different CI workflow is needed to run linter and tests, this one is just to create a release. This is because I can't really get started on the bazel side until I can create a release. I believe that @jwnrt and @nbdd0121 have more experience with linters if they want to contribute a CI workflow?

[engdoreis]

This PR look sensible to me

[rivos-eblot]

Note about SPI flash management

[rivos-eblot]

LGTM

[pamaury]

I have updated the script to change the name of the binary tarball. I am not sure how we want to name that longterm but for now I have chosen: qemu-8.0.2-ot-earlgrey-${{ inputs.release_tag }}-x86_64-unknown-linux-gnu.tar.gz.

[rivos-eblot]

I have updated the script to change the name of the binary tarball. I am not sure how we want to name that longterm but for now I have chosen: qemu-8.0.2-ot-earlgrey-${{ inputs.release_tag }}-x86_64-unknown-linux-gnu.tar.gz.

I would suggest avoiding hardcoding version number in this case. You can extract the QEMU version number with a one-line shell command such as grep 'QEMU_VERSION ' build/config-host.h | cut -d'"' -f2

./VERSION file contains the version as well, but I'm not sure whether is is combined or not with some other info at build time.

[pamaury]

Ah yes good point. As far as I can tell, those thing are the same. I'll use the VERSION file but I'll keep it in a variable so it's easy to update.