1. CodeQL is just one of the tests, it doesn't need a separate workflow.
2. It doesn't make a lot of sense running it daily, every push to the master
branch deserves a scan.
3. And every push deserves a test run as well.
publish_to_dockerhub.yml duplicated build.yml and run_tests.yml in many
ways. We always want to build docker images, it's just that we don't push them
on every occasion and there is some additional logic around the latest
tag. We also want to publish multiarch images now, so all of this logic better
be consolidated in one workflow. It doesn't depend on tests, since we only
publish on release or on manual run, so it's known to be good.
We build multiarch linux/amd64 and linux/arm64, because MacOS runner can't
build docker images and even if it could that'd be linux/amd64 while we want
linux/arm64 for Apple CPUs.
Unfortunately, given the way GitHub workflows work we can't avoid using a
Makefile helper, there is no easy way to set variables conditionally and/or
use some logic to affect their contents.
We reintroduce build_image_wsc as well here because Windows images can't be
built with buildx using GitHub runners.
Unfortunately, the default MacOS runner produces amd64 binaries, therefore we
need to set GOARCH appropriately. At the same time, docker image will be
linux/arm64, so we can build it as well.
Turns out that caching the golang:windowsservercore-ltsc2022 image between
GithubAction workflow runs is a bad idea because `docker load` command still takes
too long to load image from cached archive (~9-10min on standard windows runner).
And after that runner still needs to build the neo-go image itself.
However, standard GA windows runner is supplied with prefetched latest
mcr.microsoft.com/windows/servercore:ltsc2022 image, so using it costs almost
nothing. Thus, the other approach is implemented: we use standard
mcr.microsoft.com/windows/servercore:ltsc2022 image as both build-base and
final-base. Then we install all required tools for building neo-go manually
on build-base image (these tools are git and go 1.17). Compared to the first
approach, the publishing job (included build and publish to DockerHub)
takes ~7-8min to finish.
Rebasing or altering commits in other way is a common thing,
so it makes sense to ensure dependencies are also updated.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
This workflow tags and publishes images to Dockerhub:
* Every `push` to `master` branch
* Every release
For successful workflow runs the following secrets need to be set in the
repository `Secrets` section:
* `DOCKERHUB_USERNAME` - the username to publish images to DockerHub
* `DOCKERHUB_PASSWORD` - the password of `DOCKERHUB_USERNAME`
