In Salable, we have a custom JavaScript library for our pricing table, at a high level this JS library is responsible for displaying a product’s various pricing tables on a user’s website. This library is versioned and published to our CDN for consumption in the various framework/library wrapper packages we maintain like our React one. These wrapper packages are then able to be used in users’ applications using that respective technology.
The wrapper packages are then individually versioned and published to NPM for people to install. To ensure the wrapper packages are always using the latest CDN version of the core library, we release a new version of each wrapper package each time the core library’s version is bumped to ensure they are aligned.
This isn’t too much hassle as we already have the semantic-release package configured on both our core library and our wrapper packages. semantic-release handles all of the versioning and release workflows for us; the only manual part we need to do is update the CDN version being consumed in the wrapper package and PR it into the main branch to trigger a new version wrapper package release using the latest CDN version.
Now, I say this isn’t too much hassle but we’re developers and developers are inherently lazy and like to automate things. And, since this situation was prime for automation, we decided to automate it. But laziness aside there are good reasons to automate this workflow.
In short, the less human intervention in this type of work the better it is for everyone.
I drew up a plan to use GitHub Actions to automatically check the latest released version of the core library on GitHub and compare it to the currently consumed version of the library on the main branch of the wrapper package the action is running within.
If the versions match, we do nothing. But, if the latest core library release version is higher than the version consumed on the latest wrapper package, then we need to update the wrapper package and trigger a new release to NPM.
Inside our wrapper packages, we have a root constant.ts file which contains the core library package version we consume. It’s kept in a seperate file to make it easier to edit with bash commands inside of GitHub Actions.
I realise that might be a bit wordy and convoluted so here is a flowchart explaining what is happening in the GitHub Action being run on a CRON job within each wrapper package repository.
Now, all we need to do is add our GitHub Action! Below is the entire code of our GitHub Action with some comments explaining what each step does. We add this code into the ./.github/workflows/update-version.yml file and PR it into the main branch.
With the action now merged into the main branch, it will be triggered by a CRON job every hour on the hour, to check if the latest versions have deviated from each other and if so, update the wrapper package’s constant file to use the latest version of the core library.
Throughout this post, we’ve covered the reasoning why you might want to keep two repositories in sync using GitHub Actions as well as how to do just that with a custom GitHub Actions workflow. I hope you found this post helpful.
Developers love how easy it is to grow a SaaS business with Salable
Learn more →