Continuous integration (CI) and continuous development (CD) are bread-and-butter processes for software development. They allow developers to continually check that their code, documentation, and deployments work in the expected manner. For example, running a codebase’s test suites whenever changes are made to the codebase or its dependencies greatly reduces the likelihood that users will encounter errors when working with it. However, running full test suites whenever a commit is pushed to a codebase can give rise to a considerable amount of computational effort, which has an associated carbon footprint. For example, if someone fixes a typo in a comment, do we really need to rerun tests across various different platforms and build systems?

Green CI/CD practices are about reducing the computational cost associated with CI and CD workflows without compromising on coverage. That is, they are about seeking minimal conditions in which CI/CD workflows can be run, while ensuring that any changes are properly tested. This can be achieved in several ways, as outlined below.

Concurrency

In the context of CI/CD, concurrency refers to different jobs that are running at the same time. It makes sense to allow the same workflow to run on different branches at the same time, but in most cases it’s not useful to allow the same workflow to run for two commits in the same pull request, for example. Given that the aim is to merge the pull request into the main codebase, the most recent commit is usually of most interest. As such, we can specify that if a new commit is pushed then any running CI/CD jobs on the same branch are terminated.

Timeouts

Timeouts are another simple way to get quick wins in terms of computational efficiency. For workflows configured with GitHub Actions, the default timeout for any job is currently six hours, so if a job stalls for any reason, the runner will be unnecessarily occupied for that duration. By setting short timeouts such as 5, 10, or 15 minutes, we can avoid such wastage.

Failing fast

For workflows with multiple stages, it is important to order the stages such that failures are picked up as soon as possible. For instance, if formatting checks and a test suite are included in the same workflow then the formatting check should be done first (assuming the formatting checks are quicker to run than the tests). It would be wasteful to run an entire test suite to then find a failure due to a minor formatting issue. As a rule of thumb, start with formatting/style checks, then any other static analysis checks, then unit tests, and finally system tests.

Triggers

The fail-fast recommendation above assumes that workflows contain multiple stages. In many cases different workflows can be defined to handle the different stages. With workflows modularised in this way, perhaps the most effective Green CI/CD practice is the proper use of ‘triggers’. Here triggers refer to the conditions under which different workflows run. We should only run a particular workflow if relevant files change. So we should only run tests if files containing source code, build system code, or dependencies change. We should only run static analysis checks if there are changes to the source code that they check, or the configuration files for the checks themselves. We should only rebuild documentation if changes to documentation pages or their rendering approach are changed. (In the case of API documentation, we would also want to trigger on source code changes.) In every case, we should also include triggers on changes to the CI/CD workflows themselves.

If the above description sounds complicated then there are tools available that can configure such workflows for you. If you’re starting on a new project or adding GitHub Actions workflows to a project that didn’t previously have any then you could consider making use of the green-ci templating tool. Given your specifications of what you want your CI/CD suite to look like, green-ci will generate a set of workflows which follow the best practices outlined above. The green-ci repo also includes some documentation on the best practices applied to GitHub Actions.

Summary and further references

In summary, there are several simple ways that CI/CD workflows can be modified to reduce their resource consumption. These can be achieved by making small changes to your workflow configurations. Some of the best practices are also integrated into the Zizmor linting tool, which is designed to avoid security vulnerabilities in GitHub Actions workflows. The rationale is that resource wastage can be considered a potential malicious attack vector as well as an environmental concern.

Another useful tool for Green CI/CD is the eco-ci-energy-estimation repository, which allows you to measure the energy consumption of your CI jobs and to estimate the associated carbon footprint. This can also be configured using the green-ci tool. For further information on Green CI/CD, see (Claßen et al. 2023) and (Laskar 2025).