lf-edge
Improve cache usage on GHA for arm64 variants
Use case
GH build action builds different arm64 platform variants: generic, nvidia-jp5 and nvidia-jp6. Each build generates its own cache. However, the vast majority of the packages are the same from those built for generic platform.
Describe the solution you'd like
The cache usage can be improved by sharing the cache from generic to other platforms builds.
@rene I am starting to question the approach. There are two reasons to build different matrix runs:
- to coordinate the separate variants (i.e. having a matrix list)
- because of different build architectures (better to build arm64 on arm64 rather than emulate on amd64, and vice-versa, where we can)
The second reason goes away with variants. For example, generic and jp5 and jp6 are variants, but all are for arm64. That leaves the only reason to use matrix as a way to ensure all variants get built. I think it normally would be equally valid to use GHA matrix or to use the Makefile, e.g. make pkgs is the default, equivalent to make pkgs PLATFORM=generic, which is different than make pkgs PLATFORM=nvidia-jp6. We equally keep the platforms list in GHA and do it in the matrix, as we could keep it in makefile and do make pkgs PLATFORM=all.
The issue you raise here indicates that it is not equal, specifically for CI, there are benefits to having the ability to do make pkgs PLATFORM=all.
I propose that we do one of the two following approaches, which are changes to our current. I am ok with either.
- Keep the list in the Makefile, instead of CI, and have CI do
make pkgs PLATFORM=all(or similar), so the matrix is solely the 3 architectures - Keep the list in the CI yaml, but instead of a separate matrix run per platform, return to separate run per architecture, and in each one, do a loop of
make pkgs PLATFORM=${{ variant }}
@deitch , sorry for the long delay for replying here.... thanks a lot for your points, IMHO I prefer the approach 2. - keep the list in CI yaml and do a separate run per architecture....