Reverse engineering GitHub Actions cache to make it fast

Re:Reverse engineering GitHub Actions cache to make it fast by bob1029 on Wednesday July 23, 2025 @12:17PM (#44660891)

> they typically are going to sell you one of two things or both: support or cpu time

At what point does the line between CPU time in GH Actions and CPU time in the actual production environment lose all meaning? Why even bother moving to production? You could just create a new GH action called "Production" that gets invoked at the end of the pipeline and runs perpetually.

I think I may have identified a better canary here. If the CI/CD process takes so much CPU time that we are consciously aware of the resulting bill, there is definitely something going wrong.

[ Parent | on HN ]

Re:Reverse engineering GitHub Actions cache to make it fast by AOE9 on Wednesday July 23, 2025 @05:21PM (#44664174)

> I think I may have identified a better canary here. If the CI/CD process takes so much CPU time that we are consciously aware of the resulting bill, there is definitely something going wrong.

CPU time is cheaper than an engineers time, you should be offloading formatting/linting/testing checks to CI on PRs. This will add up though when multiple by hundreds or thousands, it isn't a good canary.

[ Parent | on HN ]