search

lowRISC / qemu

Fork of QEMU for development of lowRISC platforms (including OpenTitan)
http://www.qemu.org
Other
3 stars 8 forks source link

Add release workflow for Github Actions #11

Closed pamaury closed 1 year ago

pamaury commented 1 year ago

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.

nbdd0121 commented 1 year ago

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

pamaury commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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?

pamaury commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.