It'd be great to follow up with a small PR which enables the cache by default for the CI builds. See .github/workflows/scripts/qemu-4-build-vm.sh which handles building the packages for most runners.
Originally posted by @behlendorf in #19148 (review)
I'm creating this as an issue, in part to not forget about it, but also because, having virtually no experience with the CI system, I think it might not be so trivial (for me, not being familiar with github CI nor ZFS's particular system). And I've not yet had time to take more than a quick look at the file mentioned.
Adding the -C to enable configure caching is trivial enough, but its not that useful if the cache file is not saved and reused across builds. This could be done manually, such that each guests saves the cache files as an artifact, someone takes those and adds them to a place in the repo and new builds will use the cache files in the repo. Perhaps a more automatic way would be to have each guest look for a cache file from the previous run of the same guest type. and use that. There might be a way of using cache artifacts across builds (gitlab can do this), and maybe that would be even better to use.
We/I should probably investigate to be clear in the cases when configure will fail with a cache file it doesn't like. I know this happens when built/host/target values differ from cache file and invoked configure. Are there other reasons? This can be an issue because we're using the latest cloud images, so two builds of the same type (eg. AlmaLinux 10) may not be using the same image. Could changes cause configure to fail?
Also, implementing this should have configure re-run with a new cache if configure fails with the old cache.
Originally posted by @behlendorf in #19148 (review)
I'm creating this as an issue, in part to not forget about it, but also because, having virtually no experience with the CI system, I think it might not be so trivial (for me, not being familiar with github CI nor ZFS's particular system). And I've not yet had time to take more than a quick look at the file mentioned.
Adding the
-Cto enable configure caching is trivial enough, but its not that useful if the cache file is not saved and reused across builds. This could be done manually, such that each guests saves the cache files as an artifact, someone takes those and adds them to a place in the repo and new builds will use the cache files in the repo. Perhaps a more automatic way would be to have each guest look for a cache file from the previous run of the same guest type. and use that. There might be a way of using cache artifacts across builds (gitlab can do this), and maybe that would be even better to use.We/I should probably investigate to be clear in the cases when configure will fail with a cache file it doesn't like. I know this happens when built/host/target values differ from cache file and invoked configure. Are there other reasons? This can be an issue because we're using the latest cloud images, so two builds of the same type (eg. AlmaLinux 10) may not be using the same image. Could changes cause configure to fail?
Also, implementing this should have configure re-run with a new cache if configure fails with the old cache.