Image Source: Github

Continuous integration and continuous delivery have become the backbone of modern software delivery pipelines. It manages all aspects of the delivery process from development to deployment, further extending to monitoring and maintenance in some cases. Thus, various options are available in CI/CD tools to cater to different needs.

With the availability of cloud services, most CI/CD tools and platforms are offered as managed cloud solutions. Now, most cloud-based repository providers like GitHub have diversified their services to include CI/CD as a part of the overall GitHub platform. GitHub Actions is such a service that provides a complete and scalable solution without the management or security overhead associated with setting up a more traditional CI/CD pipeline. Thus, it will be an ideal choice for many development pipelines. However, let's look into some factors users need to know before starting with GitHub Actions.

Understand the Pricing Structure

While GitHub Actions are free for public repositories and self-hosted runners, it comes with a pay-as-you-go pricing model for private repositories and managed runners. This model includes per-minute pricing for the action usage and separate pricing based on storage utilization. Even though some free minutes and storage are included with each GitHub subscription, a growing pipeline can quickly surpass these limits.

Another factor is the minute multipliers. The base minutes are calculated considering Linux runners as the base. Yet, it does not equally correlate when running Windows or macOS runners, which multiply the minute requirements by 2 and 10 times, respectively. Therefore, unknowingly using these types of managed runners will quickly lead to rapid cost increases.

Inability to Restart a Single Step of a Workflow

GitHub Actions use YAML files called workflow files to define a workflow. A workflow will include multiple steps, but there is no option to continue or restart the workflow from a specific step when it fails, or you cancel it. The only option is to restart the entire workflow.

This inability can impact the efficiency of the pipeline as you will need to completely restart the pipeline even for small issues. For example, let's assume that you have a self-hosted agent which configures a test environment and tries to interact with the git repository when you encounter a fatal no such remote origin error due to an already existing remote named origin. There, you cannot simply go and update the remote URL or remove the existing remote and start from the errored step in the pipeline. Instead, you will have to restart the entire pipeline and start from the beginning.

Default tags on Self-Hosted Runners

By default, self-hosted runners come with pre-assigned tags, including the label "self-hosted," the CPU architecture, and the operating system without any option to stop this auto-tagging mechanism.

This auto-tagging becomes a problem if a user executes the pipeline without specifying a runner, as the build can land on any self-hosted runner. There is a high chance of builds landing on unintended runners if these runners are configured differently or run on different platforms, such as different cloud providers with various access policies, without changing the tags manually.

Using GitHub Actions Does Not Limit You To Just GitHub Actions

Most people have a misconception that using a cloud-based managed offering like GitHub Actions will limit their choices and bind them to this specific tool without any option to extend or supplement CI/CD functionality.

However, this idea is far from the truth. Extensions for actions available via the GitHub Marketplace enable extending GitHub Actions to support other services and platforms, including other CI/CD tools such as Jenkins, to security services such as SonarCloud and Snyk. This extendability allows GitHub Actions to become a powerful platform. Yet, one downside is that the available functions of these extensions may be limited compared to a native integration.

Slow Log Output

GitHub provides a robust and intuitive user interface to obtain log outputs from its runners. However, there can be instances where log output can be slow when dealing with larger log outputs. This is most obvious when dealing with self-hosted runners as their performance solely depends on the underlying hardware, and any performance issues will impact the whole platform.

No Dropdowns for Manually Triggered Jobs

GitHub actions bizarrely do not provide a way to configure a dropdown with a set of options for workflow_dispatch jobs. It is a common feature available in other tools like Jenkins but absent from GitHub Actions. Having a dropdown as an input option will introduce more flexibility to workflows and increase the overall reliability of independent workflows. It has been a highly requested feature by the community but has not been implemented so far.

Conclusion

As a part of the GitHub platform, GitHub Actions provides a tightly coupled CI/CD experience while providing ample extendability options to customize your pipeline needs. However, knowing the limitations and misconceptions about the platform before utilizing GitHub Actions will allow you to manage your expectations, leading to an overall better experience with the service.