I just don't like GitHub Actions.

# I just don't like GitHub Actions. ... GitHub Actions was launched in 2018 as a means of automating repetitive tasks. In 2019 it was updated with first-class support for continuous integration (CI) and continuous delivery (CD). The premise sounds very "GitHub": ... My intent isn't to slate the feature, but to highlight some limitations of the current implementation and to put forward some ideas. ... … There's no means of easily triggering a re-run of a workflow against the tip of a branch. Not only is this a problem when dealing with transient failures (such as a network issue during an `npm install` or `docker pull`), it also makes development of new workflows or testing changes to existing workflows difficult. It's possible to work around this by adding additional triggers, but it feels like a strange omission. # No first-class support for running locally This limitation seems common to many CI platforms: there's no obvious way to run a workflow locally to verify that it works. Third party tools like Act have put in a great deal of work to approximate the environment, but it's not easy to do so accurately. Act works by executing your GitHub Action workflows in a container. The minimal Debian images it uses by default will be unable to run the majority of workflows, but it's possible to specify your own container image. Unfortunately, the images that try to replicate the Actions environment get very large. A 12GB Docker container isn't ideal. … Unfortunately, it also reduces predictability of builds, as developers have little control over what's installed in the environment. This has a couple of effects: - In CI workflows it becomes harder to troubleshoot test failures, as it's harder to replicate the environment locally. It also makes your builds more susceptible to packaging changes made to the images, as there are far more changes to review to determine the root cause of a failure. - In build and publish workflows it makes it difficult to trust that the environment is secure. Is GitHub reliably auditing all of the software that they're installing? … # Self-hosted runners Actions provides the ability to host your own runners, so that your jobs can run on your own infrastructure and be triggered from within GitHub. This would allow us to build our own minimal image! Unfortunately unlike services like Buildkite, which can run your integration jobs on your own AWS subscription, Actions provides no way to dynamically allocate agents as they're required. … - Support for running workflows in public cloud environments would make using custom images much more accessible, and provide a fairly elegant workaround for most of the issues here. - A more minimal base image should be available, at least as an option. I think it will be difficult to retroactively add in support for SDKs, as Actions would need to be updated to detail their dependencies or risk simply not working, harming the onboarding experience for the majority.