Can we use GHA caching of the checked-out code and dependencies to reduce build burden?

[jeking3]

Analyzing the dynamic_bitset gcc-9 build job, the "Setup Boost" took 1m 8s while "Run tests" took 30s. If we're paying 1m 8s on every job, we could probably do that part once and then cache the result, and same a bunch of time leveraging GHA's caching mechanism.

[sdarwin]

It can be worth optimizing to save time.

The faster it goes, the less slow CI will be across multiple organization repos.

Cost: GHA is free for open source repositories.

[Flamefire]

There are 2 parts that consume significant time (~30s each):

1. Recursive cloning of the boost-root repo and dependency libs
2. Build of b2

We can cache 1. easily using a job the others depend on that uploads an artifact via the github action. 2. Depends on the system and optionally on the compiler. Using the actions/cache allows to reuse both, but is slightly more complex:

• We need to make sure the current library is not cached but freshly checked out. Already done by removing the libs/$SELF folder if it exists
• We must not cache build artifacts such as the bin.v2 folder
• in GHA: Cache boost checkout #241 I found that the paths inside and outside the container don't match which requires moving the folder

I guess it makes sense though -> Working on it in #241

[jeking3]

Was thinking of just caching the result of adding things from depinst so we don't have to do it over and over; one job that does depinst and pulls in all the deps, then cache that and have the posix posix jobs use it. Probably save 20 seconds per job, so it's not really a high priority.