Cache build steps and artifacts

[Jakuje]

This is an attempt to speed up the build times and reduce the resources by caching where possible:

• Letting github to install java for use and cache Maven dependencies (which take ages to download and spam the log)
• Using github action to cache APT dependencies -- they are usually the ones that take ages to download and install and most of them are same in each of the runs
• Caching the libressl build between different runs (which is still the same version for each PR and build)
• Skipping the clang-tidy from the first build pipeline as it takes ages and somehow got installed by default for some reason.

Its cumbersome at times and there is probably some place for improvement, but I think it should do the job. For comparsion, last builds on master:

• https://github.com/OpenSC/OpenSC/actions/runs/8536452439 19m 44s (I think the libressl pipeline and ubuntu-22 are the longest)
• https://github.com/Jakuje/OpenSC/actions/runs/8536607574 16m 9s (before caching the libressl build, the valgrind on ubuntu 22 still takes the most)

The setup is now much faster:

• https://github.com/OpenSC/OpenSC/actions/runs/8536452439/job/23384983306 around 30 seconds
• https://github.com/Jakuje/OpenSC/actions/runs/8536791126/job/23386052004 around 4 seconds from cache

The builds and tests still take considerable amount of time though.

[frankmorgner]

Thanks for thinking of the environment 😉

Maybe we could also use autoconf's caching, although I'm not sure if that works when we're doing autoreconf in between the new and the cached run of ./configure -C.

[Jakuje]

Maybe we could also use autoconf's caching, although I'm not sure if that works when we're doing autoreconf in between the new and the cached run of ./configure -C.

If we would like to share this among the PRs, we would have to figure out what all comes into the play of creating them (configure, Makefiles?) to base the cache on them. I can certainly try that if it will work with different suffixes to bootstrap PRs.

I just tried to see what parts of build take how much time, but ./bootstrap is roughly 6s in fresh clone in container, configure (without arguments) 6s, and make (4 threads) 35s (or 2 mins single-threaded -- not sure how many cores the GH runners have) so this should be quite small amount of time saved.

[frankmorgner]

Agreed, then it doesn't make sense to have a deeper look into this.

An other option would be to use ccache to speed up the actual build. We could use this GH action or use something like ./configure CC="ccache gcc" and cache CCACHE_DIR ourselves (see https://ccache.dev/manual/4.9.1.html)

[frankmorgner]

ccache may be an improvement for a future PR.

[Jakuje]

I was hoping I will be able to get to look into the ccache over the last month, but it does not look like the case so I will merge the current version and open a new issue for the ccache usage.