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:
Environment Configuration
Install NodeJS
Install specified NodeJS in Global Tool Configuration, install yarn as global package
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
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-NodeJSnodejs configId
is the npmrc file ID in Config File ManagementuserRemoteConfigs 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
- The release command uses
- 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.