You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
There are 2 parts that consume significant time (~30s each):
Recursive cloning of the boost-root repo and dependency libs
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
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.
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.
The text was updated successfully, but these errors were encountered: