Turns out that actions/setup-go starting with @v4 also adds caching.
With that, our cache size on disk has almost doubled, leading to the
GitHub runner running out of space in certain situation.
We fix that by disabling the automated caching since we already have our
own, custom-tailored version.
Sometimes only the "Send coverage" step of a CI job will fail. This
commit turns this step into a "best effort" step instead so that it
does not block a CI job from passing.
It can, for example, often happen that a single job is re-run from the
GH UI, it then passes but the "Send coverage" step fails due to the
"Can't add a job to a build that is already closed." error meaning that
the only way to get the CI step to pass is to re-push and retrigger a
full CI run.
This is a tradeoff of disk space (and with that cache size) and
compilation speed. Because we're still running into disk full errors
with the full build cache, we remove it for the cross compile step.
Which means we'll do more work each time.
Since we now have a scripted check that makes sure the Golang version is
synced throughout all files, it is important that the main version in
the Makefile is changed, then all other versions can be detected by that
script.
We only want to run the coverage on some select tests, since we don't
want to make tests with slow backends even slower.
And because we use "parallel: true" when uploading the coverage results,
those will only be assembled once we send "parallel-finished: true"
using the goveralls action.
So we do that with a new "finish" job.
To make it less confusing what version of bitcoind is actually
installed, we now require the version to be specified as a command line
argument.
Because we tag the version in the docker image tag as bitcoin-core:XX
but the binary internally is located under /opt/bitcoin-XX.Y/, we
manually set Y to 0.
To avoid build caches getting larger and larger, causing our builds to
fail, we separate the caches of the different job types.
If we don't separate them, then the caches can end up being a
combination of the different jobs, which isn't useful (for example the
build cache of the cross compilation build isn't useful in an
integration test and vice versa).
In this commit, rather than attempt to reduce the scope of the current
`CODEOWNERS` file, we instead rename it as a way to stop Github from
automatically assigning reviewers based on it. Instead, we put things in
a "hint" mode as a way for PR OPs to figure out who they should manually
assign PRs today.
With the CODEOWNERS file reduced to a code review assignment hint, we
aim to instead promote usage of the `@code-review` team which will use a
load balancing algorithm for automatic code review assignment.
Olaoluwa Osuntokun