Jenkins Continuous Integration - Publishing New NPM Packages

Recently there was a requirement to implement NPM package publishing with Jenkins. Here I’m documenting the configuration method.

Specific Requirements

• Execute release command to generate new version numbers and changelog records

• Submit modified package.json and changelog to GitLab repository

• Package new version to private Nexus server

Jenkins Plugin Installation

To achieve this functionality, ensure the following 3 plugins are installed:

• NodeJS

• SSH Agent

• Config File Provider

Environment Configuration

1. Install NodeJS

   • Install specified NodeJS in Global Tool Configuration, install yarn as global package

     

2. Add NRM configuration to config file

   • Select Npm config file in Managed Files, pay attention to auth config to ensure packages can be deployed to the server

     

3. GitLab credentialsId

   • Configure GitLab account private key in Global credentials

     

Pipeline Configuration

node() {

nodejs(nodeJSInstallationName: "nodejs_v10.16.0", configId: "96de5baa-02b1-4cb9-9f65-e8f96452b59c") {

stage("checkout") {
checkout([$class: 'GitSCM', branches: [
[name: 'master']
], userRemoteConfigs: [
[credentialsId: 'gitlab', url: 'git@gitlab.1991421.cn:personal/hello-web.git']
]])
}


stage("release lib") {
sshagent( ['gitlab']) {
sh '''
    git config --global user.email "alan@1991421.cn"
    git config --global user.name "Alan's 2st Bot"
		yarn install
		npm run release
		git push origin HEAD:refs/heads/master --tags
'''
}
}

}

}

File download (jenkins-release-npm.groovy)

Field Value Explanation

• nodeJSInstallationName is the specified version name in Global Tool Configuration-NodeJS
• nodejs configId is the npmrc file ID in Config File Management
• userRemoteConfigs credentialsId is the Git repository private token ID in Credentials

Notes

• Adding --tags when pushing upstream has two reasons:
  • The release command uses standard-version for version management behind the scenes. Generating ChangeLog requires tags, otherwise duplicate commit display issues occur in ChangeLog
  • Tags serve as version snapshots, beneficial for version management and issue fixing
• npm package caching is not considered here. It’s recommended to optimize this point when time permits, otherwise reinstalling third-party stable version packages each time wastes resources

Final Thoughts

• I’ve always felt that Jenkins documentation and plugins are uneven in quality, but at the same time, because Jenkins is indeed designed reasonably and cleverly, it still counts as a mainstream CI/CD tool, which is both amusing and frustrating. When actually implementing the above requirements, I still encountered some pitfalls, so I’m documenting this here as a memo
• With the above configuration, package version management is essentially handed over to Jenkins for automation. For developers, they only need to follow specifications to submit feat, fix, etc.