Auto version your node js app using GitHub Action with semantic version
A Comprehensive guide to set up CICD pipeline to test and deploy your node js project with semantic version.
Deploying an application to a server every time changes are made to the code can be quite labor-intensive. That’s where GitHub Actions come in handy. However, merely deploying isn’t enough; it’s crucial to keep track of which release includes what features or bug fixes. Without proper tracking, it’s easy to lose sight of changes made.
To address this issue, one option is to manually update the version by creating a release, detailing the features and fixes incorporated with each change. Yet, this process can quickly become tedious, requiring constant manual intervention to create new releases for every update. This is where semantic release steps in, automating the versioning process based on the changes made, saving time and effort in managing releases.
Hello guys, this is CodingWithTashi and in this shitty post, we are going to learn how to auto increment your node js application when you deploy to server.
Before we start, lets discuss few terms here
- Github Action
If you’re reading this, chances are high that you already know what GitHub Actions are. If not, GitHub Actions is a workflow pipeline that allows you to automate processes without manual intervention. - Sematic Version
Semantic version or SemVer is a version system given to any software.
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes
- MINOR version when you add functionality in a backward compatible manner
- PATCH version when you make backward compatible bug fixes
Read more from here.
Now that we’ve discussed the theory, let’s dive into practical implementation.
In this post we will
- Set up
test.yamlto test PR (Optional) - Set up
main.yamlto test build and deploy our project with semantic version.
Set up test.yaml to test PR
When working in teams, it’s common to create a branch from the “main” branch, make changes, and then raise a pull request to merge those changes back into “main.” This is where the test.yaml workflow comes into play. We don’t want to merge the PR unless the changes made by any developer pass the necessary tests. Here, you can set all sorts of rules such as unit tests, code analysis (e.g., SonarCube), and so on.
In my case I have angular node js which run karma test and if the test is pass, you will be able to merge the changes. snippet below.
Also sharing package.json script for your references.
With this code, when you create a new branch from “main” and make changes, then raise a PR against “main,” unit tests will start running to check if the PR is good to merge or not.
Cool now that PR is merge when the test is passed, Next we will run next workflow to test, build and deploy application with sematic version, this is the bread and butter of this post.
Set up main.yaml to test build and deploy our project with semantic version.
While we have set up test workflow for PR, It is good to test again in main branch before you initiate new build and that is exactly what we are going to do.
Add semantic release configuration in our project
First, We start by installing the Semantic Release package into our dev dependencies.
npm install -D semantic-releaseThen we create a configuration file for our semantic release, named .releaserc. This file will be located in root folder where package.json is added, Add below code in .releaserc
Here we are defining semantic release config, we have mention main branch and staging as branch where semantic release is done and staging is tag as pre release.
We have also added few plugin for semantic release to work such as commit-analyzer to analyze code and release-notes-generator to generate release note. You can remove @semantic-release/npm if you are not working on npm packages, At last we have added git to update our package.json file but skip ci, we don’t want to call workflow again when this change is made.
Great, before setup we need GITHUB_TOKEN from Github, Got to Profile> Settings> Developer>Personal access token>fined grained token.
Also we need Read and write permission for GITHUB_TOKEN to access and run the actions. For that, we need to have write permission. Head over to the Settings, go to Actions > General, and scroll down to the Workflow permissions section, and select the Read and write permissions radio button. Don’t forget to click the save button.
It should look something like below.
Now we can
Here in this, There are three jobs. job test, we are testing angular app
job build, we fetch updated code, installing npm packages, building angular application and upload artifact
job deploy, we are downloading uploaded artifact and deploying it firebase but you can use any other service to deploy. When the pipeline process is succeed without error. you should get new release with new version.
New release will look something like this.
And for each release, you will get release note as
Going forward when ever you made change with fix title in PR, patch version get increase and when PR with titlefeat , minor version get increase.
Note: PR title should contain fix or feat etc. eg below
You can test by creating new branch, do the changes and raise PR against main branch with mentioned title.
Read more about semantic version from here.
