GitHub Actions has become a default starting point for many teams that need to get CI or CD up and running quickly in a greenfield environment. Among other things, it can take on more complex workflows and call other actions in composite actions. Although the ecosystem in GitHub Marketplace continues to grow, we still urge caution in giving third-party GitHub Actions access to your build pipeline. We recommend following GitHub's advice on security hardening to avoid sharing secrets in insecure ways. However, the convenience of creating your build workflow directly in GitHub next to your source code combined with the ability to run GitHub Actions locally, using open-source tools such as act, is a compelling option that has streamlined the setup and onboarding of our teams.
GitHub Actions has grown considerably last year. It has proven that it can take on more complex workflows and call other actions in composite actions among other things. It still has some shortcomings, though, such as its inability to re-trigger a single job of a workflow. Although the ecosystem in the GitHub Marketplace has its obvious advantages, giving third-party GitHub Actions access to your build pipeline risks sharing secrets in insecure ways (we recommend following GitHub's advice on security hardening). However, the convenience of creating your build workflow directly in GitHub next to your source code combined with the ability to run GitHub Actions locally using open-source tools such as act is a compelling option that has facilitated setup and onboarding of our teams.
Despite our cautionary advice when we last blipped it, we've seen continued enthusiasm for GitHub Actions. What we said before still holds true: GitHub Actions is not yet a full-fledged CI/CD replacement for complex workflows. It cannot, for example, re-trigger a single job of a workflow, call other actions inside a composite action or support a shared library. Furthermore, while the ecosystem in the GitHub Marketplace offers obvious advantages, giving third-party GitHub Actions access to your build pipeline risks sharing secrets in insecure ways (we recommend following GitHub's advice on security hardening). Despite those concerns, the convenience of creating your build workflow directly in GitHub next to your source code is a compelling option for some teams, and act helps you run GitHub Actions locally. As always, we recommend a clear-eyed assessment of the trade-offs, but some of our teams are happy with the simplicity of GitHub Actions.
CI servers and build tools are some of the oldest and most widely used in our kit. They run the gamut from simple cloud-hosted services to complex, code-defined pipeline servers that support fleets of build machines. Given our experience and the wide range of options already available, we were initially skeptical when GitHub Actions were introduced as another mechanism to manage the build and integration workflow. But the opportunity for developers to start small and easily customize behavior means that GitHub Actions are moving toward the default category for smaller projects. It's hard to argue with the convenience of having the build tool integrated directly into the source code repository. An enthusiastic community has emerged around this feature and that means a wide range of user-contributed tools and workflows are available to get started. Tools vendors are also getting on board via the GitHub Marketplace. However, we still recommend you proceed with caution. Although code and Git history can be exported into alternative hosts, a development workflow based on GitHub Actions can't. Also, use your best judgment to determine when a project is large or complex enough to warrant an independently supported pipeline tool. But for getting up and running quickly on smaller projects, it's worth considering GitHub Actions and the ecosystem that is growing around them.
