Build automatically using GitHub workflow

Semphriss commented 1 year ago

Yet another feature that made me think that if it's useful for me, there's a chance it might be useful for others :)

This uses GitHub Actions to automatically build w64devkit.

This is the way I made it for myself, I'm open to bring modifications to the PR if something in there would be interesting.

The builds are triggered on either of two events:

Each commit pushed to master, and each pull request open to master, which upload builds to the Action page (example): This offers a nice an easy way to download builds for any commit on the master branch. Unfortunately, those are only available for logged in users.
Each tag pushed on the repo, which automatically uploads the builds to a new release marked as draft (example - the only thing I did manually was to publish the release): This offers a ready-made template for releases based on git tags. I tried to strictly follow the format used by the latest releases, as to minimize manual intervention, but the release is not automatically published by GitHub Actions, so manual intervention is always possible before publishing a release.

The upsides I've noticed:

The builds happen on GitHub rather than on my machine, so I don't have to wait 30 or so minutes per build before my machine becomes usable again (or before I can power it off and switch OS).
The builds run in parallel on GitHub, because it uses one VM for each architecture-flavor pair. Locally, each build would have to be done one at a time, or the machine's cores would be divided between each concurrent build.
It allows effortlessly seeing when a PR or a commit breaks the builds, and in the case of PRs, it allows the author of the PR to notice those errors by themselves without needing active feedback from others.
It offers a reliable, somewhat reproducible (or at least well-documented) environment to build w64devkit in. Also, in situations where it might be an issue, there's no need to trust that anybody didn't tamper with the files.

The downsides:

It takes 1h30 to finish all builds, and no download is available before all builds finished. For single configurations, building locally may be faster. However, for an all-configs build (6 configs * 30 minutes per config on average = 3 hours total), GitHub Actions remains faster.

If there's interest in this PR, I can explain in further detail any decision I took while creating the workflow file. I'm also willing to adapt this PR as necessary.

Peter0x44 commented 4 months ago

I'm using this, it's useful for me. It needs minor adjustments now though, there isn't a -mini version any longer.

Semphriss commented 4 months ago

@Peter0x44 I've updated the script and rebased on master.

The workflow still doesn't use the multibuild.sh script, since steps would need to be extracted to make them fit in GitHub's file format. There are still a few minor differences between the script and the workflow file, notably about the version suffix. I preferred to leave it like that since it makes the maintenance of the workflow easier, but I'm open to update it as necessary.

Peter0x44 commented 2 months ago

The fortran variant is now gone, so I think this will need a few adjustments.

skeeto commented 2 months ago

Yup, I'm about to make a new 2.0.0 release with significant distribution changes. It's now a self-extracting 7-zip archive, and gfortran is always included. The two release artifacts will be named:

w64devkit-x64-2.0.0.exe
w64devkit-x86-2.0.0.exe

Like when I got rid of "mini", I want to simplify it for newcomers, so they don't have to make a decision about which to download. It's just 64-bit and 32-bit, with 64-bit (deliberately) sorting first. These releases are also a third of the size of the originals and extract ~100x faster (literally!) than Windows built-in zip support.

I hope this will also help with virus scanner nonsense, because extracted files won't have Mark of the Web (i.e. "forbid this file from any use"), which Windows built-in zip support does, but 7-zip, especially the self extract, does not. If someday I figure out how to navigate Windows code signing, signing just the SFX will be enough.

Peter0x44 commented 2 months ago

On the subject of signing, there is some discussion here in msys2 for doing it to the installer: https://github.com/msys2/msys2-installer/issues/73#issuecomment-2256287612 Though, there are no satisfactory options available yet.

skeeto commented 2 months ago

Thanks, Peter0x44, that's useful information!

Semphriss commented 2 months ago

I've updated the workflow file to w64devkit 2.0.0.

skeeto / w64devkit

Build automatically using GitHub workflow #72