ci: Bump GCC snapshot major version to 16 #1690

1. 
   hebasto commented at 8:12 pm on June 19, 2025: member
2. ci: Bump GCC snapshot major version to 16 add146e101
3. 
   maflcko commented at 8:54 pm on June 19, 2025: contributor

   lgtm ACK add146e1014a6d5c585bbf3e10a765c87194b795

   It could make sense to also clear the container image cache every few months to get a more recent snapshot on the same branch

4. real-or-random added the label assurance on Jun 20, 2025
5. real-or-random added the label ci on Jun 20, 2025
6. 
   real-or-random commented at 6:40 am on June 20, 2025: contributor

   Thanks, I’ve also subscribed to gcc-announce now to be notified of new major releases.

   It could make sense to also clear the container image cache every few months to get a more recent snapshot on the same branch

   Indeed, we need to do this manually, but we have no rule for it. I suggest doing this as part of the release process, simply because that one is supposed to happen every 3–4 months.

   Ideally, we’d clean the cache at some meeting a few weeks before the release, so we test on the latest version before. That rule is harder to follow than just cleaning the cache after the release, but it would be unpleasant to do a release and notice an hour later that it will break with the next GCC or Clang release. I suggest trying with “~four weeks” before the release, and if we forget it, then well, we can still clean the cache immediately before the release. In the worst case that we really encounter a serious issue (unlikely), the release needs to be pushed back a few days.

7. real-or-random approved
8. 
   real-or-random commented at 6:40 am on June 20, 2025: contributor

   ACK add146e1014a6d5c585bbf3e10a765c87194b795
9. real-or-random merged this on Jun 20, 2025
10. real-or-random closed this on Jun 20, 2025

    ---

11. 
    real-or-random commented at 6:48 am on June 20, 2025: contributor

    Hm, I wonder why the cache on our master has been rebuilt just 4 days ago (except the first build stage, which is just a 32 byte cache of an essentially empty docker container.) This screenshot has been taken immediately after I clicked merge here, so before the interesting build stages of the new master build have finished:

    

12. 
    maflcko commented at 6:51 am on June 20, 2025: contributor

    I am not familiar with the GHA caches, but they may expire after a few days (7 according to https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows#usage-limits-and-eviction-policy)

    So everyone holding back from creating/merging a pull request for a week may be enough, but seems unreliable.

    Indeed, we need to do this manually, but we have no rule for it. I suggest doing this as part of the release process, simply because that one is supposed to happen every 3–4 months.

    Sounds good. If this is moved to github actions (https://github.com/bitcoin-core/secp256k1/pull/1689), I don’t know how to implement it, but my guess would be that it is sufficient to add a dummy text to the dockerfile. Something like:

    0# Invalidate build cache before a release
    1# insert YYYY-MM (or expected release version number)
    2...
    3# Build and install gcc snapshot
    4ARG GCC_SNAPSHOT_MAJOR=16
    

13. 
    real-or-random commented at 6:54 am on June 20, 2025: contributor

    Hm, I wonder why the cache on our master has been rebuilt just 4 days ago (except the first build stage, which is just a 32 byte cache of an essentially empty docker container.)

    Ah, most likely due to this rule I had forgotten about:

    GitHub will remove any cache entries that have not been accessed in over 7 days.

    https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows#usage-limits-and-eviction-policy

    This matches the merge history. It appears that low activity sometimes pays off. :)

    I also found this: We can use a GHA cron job to delete the cache every few weeks automatically. This seems much better.

14. 
    real-or-random commented at 6:57 am on June 20, 2025: contributor

    Sounds good. If this is moved to github actions (#1689), I don’t know how to implement it, but my guess would be that it is sufficient to add a dummy text to the dockerfile.

    If you have write access, you can just click a button. But the automatic thing I mentioned above seems better.

15. hebasto deleted the branch on Jun 20, 2025

Contributors
hebasto maflcko real-or-random

Labels
assurance ci