DEV Community

Cover image for GitHub: Composite Actions vs Reusable Workflows [Updated 2023]
Davide 'CoderDave' Benvegnù
Davide 'CoderDave' Benvegnù

Posted on

GitHub: Composite Actions vs Reusable Workflows [Updated 2023]

Understanding the differences between Composite Actions and Reusable Workflows in GitHub Actions can be more complex than you think… especially after the latest changes GitHub made.

But hey, I’m here for you. Let’s find out together what those 2 features have in common, what the differences are, and when you should use one instead of the other.

Into

I’ve already written an article and made a video on this subject before, however that was almost 1 and a half years ago and, as many pointed out in the comments , GitHub has substantially changed the featureset since… so it’s time for an updated comparison.

Btw if you want to have a deep dive into either Composite Actions or Reusable Workflows, be sure to check the in-depth videos I made about them (here and here).

Video

As usual, if you are a visual learner, or simply prefer to watch and listen instead of reading, here you have the video with the whole explanation.

Link to the video: https://youtu.be/zc19mR3O4a4

If you rather prefer reading, well... let's just continue :)

About Composite Actins and Reusable Workflows

In general, Reusable Workflows are a way to avoid duplication as you can reuse the same workflow in multiple other workflows, and perhaps create a library of proven and effective workflows that can be centrally maintained.

Composite Actions, instead, allows you to combine multiple steps within one action. For example, you can use this feature to bundle together multiple run commands into an action, and then have a workflow that executes the bundled commands as a single step using that action.

And this brings me to the first difference between the 2: Visibility and Logging.

1. Visibility and Logging

I think this point is pretty important but often overlooked.

With Reusable Workflows you have a very rich log of what is happening, and every single job and step is logged independently in real time as you can see below:

Reusable Workflows Logs

This specific workflow has 2 jobs in it, and each job is logged together with its steps. All clear and organized.

Composite Actions Logs

This is not the case, however, with Composite Actions. As we have just seen, Composite Actions are a way to group multiple steps in one… this also means that when executing that step you don’t have visibility on all of the parts.

Multiple Jobs

All you have is a single log of a single step... even if it contains multiple steps.

2. Jobs

Another difference, which is the biggest difference in my opinion, is about Jobs.

As we have said before, Composite Actions allow you to only have a flat list of steps. Therefore, you cannot have multiple jobs in a single Composite Action.

In fact, a Composite Action doesn’t even specify a job keyword, but uses runs instead, and can only be consumed from within a job in the caller repository.

No Jobs in Composite Actions

Because of this, you can see a Composite Action basically like any other action you have on the marketplace.

The story is different, however, for Reusable Workflows.

They do define jobs inside them, and because of that you can have as many jobs as you want in a single Reusable Workflow.

Jobs in Reusable Workflows

And since they do use jobs, and you have to specify where the job will run, we can take this a little further: if your job needs to run on a specific runner or machine, you need to use Reusable Workflows.

3. Calling them

Next, and actually last, difference between Composite Actions and Reusable Workflows is how you call them, and this tightly relates to what we have seen previously.

Reusable workflows are called directly within a job definition, and not from within a job step.

Calling a Reusable Workflow

You cannot, therefore, use GITHUB_ENV to pass values to job steps in the caller workflow. And, more importantly, you cannot add additional steps to the job which calls the reusable workflow.

Composite Actions, instead, can exclusively be called and used as a step in a job, which also means there could be (and that is usually the case) other steps in the job before and or after the Composite Action.

Calling a Composite Action

Make sure to keep this difference in mind when designing your Actions Workflows.

Conclusions

There used to be many more differences between Composite Actions and Reusable Workflow, but as of recording this video, the only ones still standing are the 3 differences we have just seen.

So, to recap, Reusable Workflows make it simpler to spin up new repositories and projects and immediately start using automation and CI/CD workflows with GitHub Actions that you know will work, and to reduce code duplication.

Composite Actions, on the other hand, allow you to pack multiple tasks and operations in a single step, to be reused inside a job.

Let me know in the comments below if you noticed any other point in which those 2 features differ, and if you prefer using Composite Actions, or Reusable Workflows… or both 😉

Also, check out this video, in which I talk about the new GitHub Actions Larger Runners and how to use them.

Like, share and follow me 🚀 for more content:

🆘 Get Help With DevOps
📽 YouTube
Buy me a coffee
📧 Newsletter
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱‍💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast
💖 Patreon

Buy Me A Coffee

Top comments (3)

Collapse
 
cicirello profile image
Vincent A. Cicirello

Nice summary of differences. Your examples would be much easier to read if you had them as code blocks within the post rather than as images.

Collapse
 
n3wt0n profile image
Davide 'CoderDave' Benvegnù

Thanks for the feedback. The reason why I used images is because I wanted to show "real" examples... but come thinking of it, I see your point... I will consider it for the next articles! Thanks again

Collapse
 
imcodebased profile image
Amit Malhotra (imcodebased)

major difference is when you have to call a shall script within.