[jkbonfield]

This is designed to ask the question:

"If we made a release today, would the tarballs pass the extract, configure, build and test workflow?"

Each individual repository already does its own tests, but we don't know if the tar asset creation is valid and there may be other niggles. This also opens up the possibility of periodically running much slower CI here and reducing the on-push CI burden in the individual repositories. Eg adding emulation of other CPU platforms, 32-bit machines, etc here, and removing the overly slow macos address-sanitizer build from the main repos.

We have x86-64 VM tests using qemu (FreeBSD, OpenBSD, Solaris) and container based builds using linux images (alpine, archlinux, centos, rockylinux, and opensuse), along side the traditional ubuntu, windows and macos pipelines.

We test htslib in isolation as well as integration testing of samtools+htslib and bcftools+htslib tarballs.

[jkbonfield]

You can see a completed run here:

https://github.com/jkbonfield/c-maint/actions/runs/29994331286

Note this fails bcftools tests on alpine due to an assumption of gunzip supporting -f to read uncompressed data, which doesn't work with Alpine's busybox. (A fix for this is in the bcftools CI PR as it's necessary to verify the CI works, but I could move that commit to a separate PR if required.)

[daviesrob]

Would it be a good idea to limit scheduled runs to the samtools/c-maint repository, as done for the container building? It has to be done by an if-condition on the job (as done here). The reason would be to stop all forks from eventually trying to run a build at exactly the same time as the one we want to happen.

[jkbonfield]

I thought of that, but then we'd need to comment it out if we ever do any editing of the workflows, otherwise we couldn't test things until we made a PR. Inevitably the nature of CI work is you have to test online rather than locally, so that is a pain point.

I don't see the problem therefore, as the only times it would run in duplicate is the final time that the user has pushed it and is now happy to make the PR with their changes. In that case they can cancel the actions if they so desired. It feel like less hassle than commenting out lines and having to remember to uncomment them again on PR creation.

[jkbonfield]

Oh wait, sorry I see what you mean. I don't know tbh if they do run on old branches. That's an interesting point. I'll check

[jkbonfield]

Commit jkbonfield@0235e8e#diff-b956afa69dd50bb0a565a048fea004b7e6c7ded40f35e168cbffa613bab3ffbf contains

# Build and cache the release tarballs
name: Test tarballs
on:
  schedule:
    # Every Sunday at 3:15am GMT
    - cron: "15 3 * * 0"

Yet my Actions tab doesn't contain any scheduled runs.

According to my friendly LLM, schedule only triggers on the default branch. On forks, it's also disabled on the default branch too unless explicitly reenabled. That backs up my observations showing no actions in the two months the PR has been waiting.