This means that you are able to run a ton of tools without any explicit setup steps. It also means they have to maintain all that stuff "forever", and the versioning is very inexact. I feel like this issue is a symptom of that choice. Their base images are huge, though I can't find exact numbers right now since there's not actually any official images for it.
Another issue is that if you try to use a self-hosted runner, all of your actions will break because the self-hosted runner is missing all the preinstalled software. This was pretty confusing to me because this seems to go against the "reproducibility" aspects of a CI. There's not even an (official) way to run GitHub actions locally, so you immediately become dependent on the Microsoft-hosted offer. To me it feels like this was maybe even intentional so you have to buy up their expensive compute minutes when running the same things on a bunch of VPSes is much cheaper.
This is all opposed to GitLab, which solved the same issues years earlier. Here you have to chose your images yourself. It's a bit more work to setup an action because of it, but in my opinion it's much more sustainable and has less surprises in the longer term. There's a single simple command to just run an action locally, and you can easily deploy a runner that will work exactly like the hosted version.
With Github, it's a good idea to print the versions of anything you expect to be installed at the start of CI. Ensures it's actually installed and makes it easier to track down version differences.
Or you directly build the images like GitHub or Azure DevOps so you have your „reproducibility“ again, as everything is inside the images as the hosted ones:
Github rolled out a breaking change to Github-hosts Action Runners, that breaks `brew install`
They did not follow their own commitment of announcing a breaking change 1 month before roll out nor do they provide a way to opt out or use an older version of their image.
Moreover, their suggested fixes are incomplete or just don't work.
I assume you're right in the context of desktop computers. I wonder if, in the context of GitHub images, you might have a situation where many of the folks creating things to run on them are macOS users by default and would reach for the tool they're most familiar with.
This means that you are able to run a ton of tools without any explicit setup steps. It also means they have to maintain all that stuff "forever", and the versioning is very inexact. I feel like this issue is a symptom of that choice. Their base images are huge, though I can't find exact numbers right now since there's not actually any official images for it.
Another issue is that if you try to use a self-hosted runner, all of your actions will break because the self-hosted runner is missing all the preinstalled software. This was pretty confusing to me because this seems to go against the "reproducibility" aspects of a CI. There's not even an (official) way to run GitHub actions locally, so you immediately become dependent on the Microsoft-hosted offer. To me it feels like this was maybe even intentional so you have to buy up their expensive compute minutes when running the same things on a bunch of VPSes is much cheaper.
This is all opposed to GitLab, which solved the same issues years earlier. Here you have to chose your images yourself. It's a bit more work to setup an action because of it, but in my opinion it's much more sustainable and has less surprises in the longer term. There's a single simple command to just run an action locally, and you can easily deploy a runner that will work exactly like the hosted version.