CI study

[finalyards]

I did some study on the Github Actions, yesterday.

My learnings:

Freeing disk space is not "free"

It takes:

path	min	max
/usr/share/dotnet	6s	23s
/usr/local/lib/android	39s	2m55s
/opt/hostedtoolcache/CodeQL	4s	20s

This feels strange, of course, but maybe Azure/GitHub uses some kind of layering file system (similar to docker's), and the thousands of files need to be layered off, instead of just wiped. We wouldn't know.

If it was <10s, cleaning disk space would be a good idea. Now, I think it's not.

Other options: Caching

In .github/workflows/ci.yaml both the steps (build and binary-size) use the same caching (1 and 2). I don't think this is needed, or a good idea.

• build causes a cache of 2.3GB (fresh run, no passed-on caches)
• binary-size causes a cache of only 230MB

Most importantly, I think they cache partly different things. I would separate them. (though keep binary-size defaulting to the build cache if only that is available - it's a small trick to hyper-optimize this. Which is cool. Just cool.)

Sequential

@lulf mentioned earlier that it would be welcome to do the cargo fmt / clippy tests early, to fail fast. I wonder if there's a reason why the two jobs are currently being run in parallel. I would make the sequential - which can be done by adding a single line:

  binary-size:
    needs: build        # run only if 'build' succeeds

This might mean slightly longer overall CI times, but I think it's a meaningful use of resources to first see things "look fine", then do the heavier work (binary-size being rather heavy at 3m).

In fact (💡) - would you be open to separating the fmt/clippy parts to a preceding, third step, then depending both the "build" and the "binary-size" from that. I think this could be sweet: minor change to existing CI setup but guarantees fast fail on misformatted stuff.

Next steps

I can probably pull down the CI times to around 6 min - from current >10 min.

To see more of my experiment, see here: https://github.com/finalyards/trouble.fork/blob/ci-study/.github/workflows/ci.yaml

[HaoboGu]

Yes, that's quite weird that cleaning /usr/local/lib/android needs 2m55s. It would be great if your approach works and makes the CI faster

[finalyards]

Looking at the repo's use of cache:

1. The main cache seems to have bloated to 4.9 GB (only 2.3GB are needed)

2. The two steps actually do use different caches, already, but it's not by design.

   The binary-size fails to provide a hash, and ends up with its own cache name (Linux-cargo-).

A fast way to ease the CI disk space use, and to speed it up, would be to just remove both the larger (4.9GB) caches. I cannot do that. They'll grow back over time, but start at 2.3GB. Ideally, we'd keep a track of their size - or see if an expiration size can be set in GitHub Actions itself.

[finalyards]

PLEASE DON*T REMOVE THE CACHE, YET.

I'd like to take a peek on its internals.
EDIT:

I seem to need some help. The CI is in a weird state, unable to populate the cache:

I'd like someone (@HaoboGu @lulf ?) to:

• remove one of the 4.9GB cache files here - but keep the other, for now.
• then I'll retry running this thing - to get an understanding what's unnecessary in the 4.9G.

Once we have that information, also the second large cache files can be disgarded.

Note:
The current caches, uncompressed, amount to 18GB of disk use.

[finalyards]

Caches can be removed.

The reason some of them miss the hash part is straightforward: The checkout step needs to be before cache - now it's not for binary-size, so by the time the hash is calculated, the files are not yet there. Easy to fix, but I'd like to have a good conversation about the caching/locking strategy, first. Hope we can arrange that.