rocksdb has its own internal option that overrides the cpu
target, so we need to be sure to tell it not to do that
using this option, otherwise we can cause illegal instruction
errors in the resulting executable.
I'm seeing some illegal instruction errors on the build cluster
and I suspect that something is being tuned to a cpu on one
node and isn't 100% compatible with another node.
This commit arranges for the image builder to produce a static
build of rocksdb, and then for the populate-cache-vars.sh script
to detect that and update the environment so that the build picks
up that pre-built rocksdb instead of building a vendored version
of rocksdb on every CI run.
aws-lc-sys refuses to build with it. aws-lc-sys is a dep of rustls.
gcc-9 is normally present in ubuntu-20.04.
The bug is not present in clang (what we end up with on ubuntu 20.04
when we uninstall gcc-9) and gcc-10.
We need to avoid recursively copying any symlinks-to-dirs as
directories. We can do that with cp, but the parallel xcp utility
doesn't support the --no-dereference flag at this time.
refs: https://github.com/tarka/xcp/issues/52
This is essentially a refactoring of the stuff that we've been running
on GH, but broken out to run on our woodpecker instance.
I've removed sccache from the image; it's actually been failing the
build on amazonlinux:2, but the GH action version of the build has
been showing up as green(!)
use the drone cli to check that the starlark is well-formed,
and to try to run a build.
Useful for sanity checking a pending CI commit.
Slim down the deps very slight on ubuntu systems.
The drone plugin does stuff very strangely and is incompatible
with our approach.
Do it ourselves (with blackjack and ...), so that we can avoid
cloning and bloating the repo.
Wez Furlong
drone