Jenkins Continuous Integration - Publishing New NPM Packages

· 2 min read · 376 Words · -Views -Comments

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

  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.
Authors
Developer, digital product enthusiast, tinkerer, sharer, open source lover