Building Efficient Node.js Workflows in GitHub Actions: Leveraging Caching and Modular Job Structures

As Software Developers, we love automation, be it automating tasks or using that automation. One such automation is CI/CD pipelines, and one of the most widely used platforms for CI/CD is GitHub Actions.

It is crucial to learn the platform that we are using and the features that it offers to build efficient and reliable automation.

One of the most common automation workflows used in Git-based Software Development is PR/MR checks, these checks have become an essential part of modern CI pipelines as they help maintain the source code and improve PR/MR reviews.

In this article, we will focus on creating a PR checks workflow for a Node.js application using GitHub Actions, and how we can improve the DX of the workflow and make it more efficient using modular jobs, and caching.

Prerequisite

• What is and
  
  
  

  Now, let's checkout the repository, setup node, and install dependencies:
  
  
  
  Voila!, we have a nice workflow automation that will benefit our development process.

  
  
  

  Or is it?

  
  
  

  
  
  
  The Issues
  

  
  
  

  You see this automation looks fine at first, however, it has some issues:

  
  
  
  
  
  • All our tasks are crammed into one job.
    
  
  
  • On the GitHub Actions dashboard, the workflow diagram will look something like this:
    
    
    
    

    This solves all our issues! Each task runs in a separate job, so we don’t have to dig through logs to figure out where things went wrong. Plus, we get a nice diagram on the dashboard showing exactly which task failed. From there, we can dive right into the logs of the specific task to investigate further.

    
    
    

    , you can also access this cache in your or you can set up to cache our dependencies from our first job run and use that cache for subsequent jobs.

    
    
    

    However, we have something even better. actions/setup-node has

    
    
    

    It gets even better, actions/setup-node defaults to searching for the dependency file (package-lock.json, npm-shrinkwrap.json, or yarn.lock) in the repository root, and uses its hash as a part of the cache key, which means any subsequent workflow runs will use the same global packages cache if the lock file is unchanged (i.e. no changes in the dependencies) or till the

    
    
    

    
    
    
    Conclusion
    

    
    
    

    Using the actions, modularity, and caching features in GitHub Actions, we developed an effective and efficient workflow to automate our pr-checks. Similarly, we can utilize these features in other CI/CD operations and contribute towards improving project workflow.

    
    
    

    If you enjoyed this article and want to connect, feel free to reach out on .

    Vollständiger Original-Bericht

    Ausführliche Details, Code-Beispiele & Hersteller-Stellungnahme auf dev.to.

    ↗ Original-Artikel auf dev.to lesen