Split job steps as single jobs and keep the environment?

I’m currently running checkout/tests/lint steps in the same job/workflow in order to avoid multiple envirnoment setup and dependencies install.

This lead though to the same “Check failed” error for different steps failure. That means is harder to understand at glance if formatting or tests failed.

This is the current state:

name: Test and Lint

  branches: [master]

runs-on: ubuntu-latest
       -name: # checkout
-name: # lint
-name: # test
-name: # publish_results

I’m basically looking for something like this, but with shared environment, so that I don’t have to checkout code everytime:

name: Test and Lint

  branches: [master]


needs: checkout

needs: lint

needs: test

How long do your steps currently take? Checkout should be negligable compared to the other steps. It’s usually better to present your real use case instead of trying to optimize stuff that could only give you marginal benefit even if you succeed.

Hi @dlime , 

In Github Actions jobs run on different hosted runners. Those different runners are installed in separate viturl machines, so you need to add checkout step in each job.  

As Cyberbeni said, the checkout time is very short, so checkout should be negligible compared to the other steps. For the dependencies, you could use actions/cache to cache those dependencies, and you also need to add this step in each job. 

Thank you for your answer, I’ll use action/cache since installing dependencies is what takes most in my runs.

I will split the linting in a different “job” even if it sounds counter intuitive to setup another runner/checkout code when it’s already done before for building job

Hello Cyberbeni,

Thanks for the answer, I wasn’t concerned about execution time, just about efficiency:

  • why using another runner + checking out code when I did it already in a previous job?

  • so, is it possible to share the environment in the different jobs on same workflow?

Keeping everything inside a “God” job that does checkout + lint + tests make:

  • too generic “build” job

  • too generic “check” failed in the commits (which step actually failed? gotta click to the job log)

1 Like

I share the same opinion.
Having separate jobs and being able to understand if your workflow failed on ‘install’, ‘test’, ‘build’ or ‘deploy’ is really useful instead of having a single block of steps where you cannot be sure where the error happened until investigating.

Below, are two different Workflow email notifications, I got from Github upon a failure:

Single job, many steps:


Multiple jobs:

I guess this makes the need of being able to pass state between jobs, very clear?

Having to ‘checkout’ on every single job, and then install dependencies, even if it loads from cache, takes time.

Unfortunately, I’m not yet very convinced this is a sensible way of solving this problem.
I think GitLab has this implemented in an intuitive way with their Pipelines.