Since the Introduction of GitHub Actions in 2018, many organizations have migrated their CI/CD workloads from third-party solutions to GitHub. This is due to the proximity of code to the CI/CD workflow, which improves the software delivery experience and efficiency.
In a previous article, I emphasized the concept of DRY (Don’t Repeat Yourself). I also introduced Mono Chart, a technique to avoid Helm Chart repetition in Kubernetes deployment. This time, we will explore another application of the DRY principle in CI/CD. This time, we shall compare two options that exist in Github Actions. Which are:
- Composite Action
- Reusable Action
First, let’s begin with the definition of a Composite Action.
What is a Composite Action
According to Github Documentation: Composite actions allow you to collect a series of workflow job steps into a single action, which you can then run as a single job step in multiple workflows.
What is a Reusable Workflow
According to Github Documentation: Reusable workflows provide another way of avoiding duplication (aka DRY), by allowing you to run a complete workflow from within other workflows.
Both definitions sound alike; it seems like a repetition, right? Let’s first look at the similarities between both functionalities and then their differences.
How Similar are they?
Both Composite Actions and Reusable Workflows are strategies to prevent repetition when setting up GitHub Actions. Instead of duplicating workflows across different repositories, you can opt for either a Composite Action or a Reusable Workflow to streamline your configuration.
Composite Actions and Reusable Workflows use theworkflow_call command in Github Actions for trigger.
Now that we understand the similarities, let us talk about their differences.
What are their Differences
Structural Differences
For a Composite action, the repository must have a file in the root directory with the filename action.yml which is the file that activates the workflow
For a Reusable Workflow, the workflow file needs to be located in the .github/workflows/action.yml . The file name must not be action.yml
Script Differences
Composite Action does not support secrets parameters when defining it. They only support inputs parameter receiving input.
Reusable workflows support both secrets and inputs for receiving input.
In Composite Action, it needs to be explicitly specified under the runs block that it is a composite action
In a Reusable workflow, you do not need to specify anything
In Composite Action: For each step, the shell that is used to run the bash script in that step needs to be explicitly specified
In Reusable workflow: There is no need to specify the bash type.
In Composite Actions, Steps are grouped under runs
In Reusable workflows, Steps are grouped under jobs
Application Differences
In Composite Actions, one Composite action is one with its Git Repo. Another new repo is needed to run multiple Composite Actions
In Reusable Workflow, a single repo can have multiple workflows, and each is referenced differently
Sample Usage: Reusable Workflow vs Composite Action
Reusable Workflow
uses: MyCloudSeries/deploy-app/.github/workflows/deploy.yml with: service_name: myapp environment: dev url: myapp.mycloudseries.com
- name: Deploy My Application
uses: MyCloudSeries/deploy-action@v1
with:
service_name: myapp
environment: dev
url: myapp.mycloudseries.com
Recommended Application Scenarios
If you need flexibility in your workflows without the constraints of Composite Actions, Reusable Workflows are likely a better choice. However, if you’re planning to publish the action on the GitHub Marketplace, it must be a Composite Action. In short, Reusable Workflows are ideal for internal use within an organization, while Composite Actions are more suited for external sharing outside an organization.
Pros of Reusable Workflows vs Github Actions
Composite Actions
Publishable: You can publish Composite Actions to the GitHub Marketplace, making it easy for other users to incorporate them into their workflows.
Easy to Set Up: Useful for combining multiple steps into a single action, reducing complexity in individual workflows. It starts with having a repo in your organization with the name actions, and the workflow file located in the root directory with the name action.yml .
External Sharing: It can be utilized across multiple repositories and by other users or organizations when published in the GitHub Official Marketplace.
Lightweight and Self-contained: Composite Actions are usually simpler and can be ideal for smaller tasks where a full reusable workflow isn’t necessary. It combines multiple steps in a single action, which simplifies the integration into workflows.
Reusable Workflow
Flexibility: You can reuse entire workflows, including complex job orchestration, conditionals, matrix strategies, and environment setups. It allows the utilization of multiple jobs, parallel jobs, and matrix builds.
Job Control: It supports all features of regular workflows (e.g., multiple jobs, conditionally running jobs, matrix configurations). It also enables the sharing of workflows between various repositories within an organization or even between different organizations
Easy Maintenance: If you have common workflows (e.g., CI/CD pipelines, deployment processes), you can define them once and reuse them across different repositories, reducing duplication and making it easier to maintain.
Support Native GitHub Features: Reusable workflows support everything available in standard GitHub workflows, like secrets, job dependencies, services, and more.
Conclusion
Reusable Workflow and Composite Action ensure DRY is enforced when writing deployment scripts in Github via Github Actions. Applying each of them in their proper landscape will yield the best benefit. In addition to applying them in the appropriate use cases, ensuring optimal steps and jobs is essential for creating an efficient GitHub Action workflow.
References
- https://docs.github.com/en/actions/sharing-automations/creating-actions/creating-a-composite-action
- https://aws.amazon.com/codepipeline/
- https://docs.github.com/en/actions
