Adding Caching to Kivy CI pipelines

[p0lygun]

GitHub actions have been immensely helpful in various CI flows in Kivy Orgs, but they take a lot of time, even more than 30 minutes sometimes.

Going through workflow files, I can see many points in the CI where we can add caching to decrease the runtime/build time of many workflows saving Quite a few CPU cycles in the process.

I will be doing this over the next week or so, but first comes identifying and discussing the correct strategy to go about it.

Few this to kick this off.

• Github Caches Policy
  • Any cache that is not accessed for 7 days will be deleted
  • We can store any "number" of cache items
  • Max space available to store cache in 10 GB.

@misl6 thoughts on this please?

[misl6]

Well, I usually took the chance to go for a walk while waiting for our CI flows to complete, so that change is going to impact my back pain.

Seriously, improving the speed of our CI flows is definitely something really appreciated.

Just consider that:

• On self-hosted runners, may be less time-consuming to re-download the source + build sometimes (the performance is better compared to Github Hosted runners, but the download speed from cache servers is not). Feel free to experiment and compare.
• Sometimes (p4a, kivy-ios, buildozer), we need to re-build things from scratch. Here we should think about creating a pre-built packages archive (not only for the CI, but also to improve the developer experience)

[Julian-O]

• Buildozer has a lot of overlapping feature-suggestion issues (I am thinking about how to consolidate them) regarding caching of downloads and caching of partially compiled source, so that (a) subsequent runs run faster, (b) there is less Internet usage (where that is expensive) and (c) so initial builds run faster [by having caches available on the Internet - e.g. wheels]. I don't know what you are planning here, but consider if the ideas can be re-used by Buildozer users.

• When I work on a fork of Kivy Buildozer, I copy the actions from the main fork, and they are very slow (hours or days) in discovering that there are no MacOs runners that are going to come and run the ios unit tests. Fixing that would be helpful (ideally, making it so the tests run, but if they can't, failing faster.)

[Julian-O]

Please consider weekly runs of the full tests - e.g. building all the recipes even if they haven't changed.