What are the best practices for Github Actions when it comes to splitting a wofklow into multiple jobs?

Question

I'm trying to understand the best practices of Github Actions when splitting a workflow into multiple jobs.

First of all, is it generally a good idea to split a workflow if the steps are logically indepentent?

The most classical example, let's take a project with a build, a test and a deploy step. Is it generally better to split the three steps into three different jobs, even if they can be see as sequential (deploy depends on test that depends on build)? What are the pros and cons of spltting vs keeping a single job?

Also when splitting, is it a good practice to just checkout and rebuild the project entirely? This obviously creates some overhead and potentially some small differences. For instance during build one might use multiple versions of a language, while during deploy only one would be used.

What are the best practices and the rational behind them? Is there any good tutorial on this?

Answer 1

What are the best practices and the rational behind them?

I am generally guided by two principals:

• MTTF - Mean Time To Feedback.
• DRY - Don't repeat yourself.

I won't spend much time on MTTF since it's rather off topic to your question, but I will say that if one approach dramatically reduces how long it takes to get feedback (good/bad) to the relevant parties, I will generally prioritize that over all other concerns.

DRY - when I make a change I don't want to have to go through 30 different builds to make the same change, so I try to standardize the builds as much as possible.

What are the pros and cons of splitting vs keeping a single job?

• If you have a matrix of build steps splitting can help with with DRY.
• Single linear jobs are typically easier to read (unless doing so violates DRY).
• Split jobs typically make it easier to restart part way through a process - for example if you fix a test you may not need to rebuild a binary (can help with MTTF).

Also when splitting, is it a good practice to just checkout and rebuild the project entirely

Probably not - it's generally better to store/cache outputs of stages - for example binaries/docker images can be place into a repository.