I am trying to setup CI on Azure DevOps Pipelines, on Hosted Ubuntu agent for a nodejs project with auto incrementing version numbers.
I am getting the errors on the incrementing the version using npm version patch
[command]/opt/hostedtoolcache/node/8.12.0/x64/bin/npm run release-it
npm ERR! Git working directory not clean.
npm ERR! M package-lock.json
> identity#2.0.2 release-it /home/vsts/work/1/s
> npm version patch && git push --follow-tags
npm ERR! A complete log of this run can be found in:
The error persists even if I don't push to git.
As a part of the CI, I have cleaned the repo
resources:
- repo: self
clean: true
trigger:
batch: true
branches:
include:
- '*'
pr:
autoCancel: true
branches:
include:
- 'master'
jobs:
- job: identity_release
timeoutInMinutes: 20
workspace:
clean: all
pool:
vmImage: 'ubuntu-16.04'
demands:
- npm
condition: or(eq(variables['Build.Reason'], 'Manual'), eq(variables['Build.Reason'], 'Schedule'))
steps:
- script: echo The build reason is $(Build.Reason) and branch is $(Build.SourceBranch)
- template: release-build-steps.yml
I have cleaned the build sources directory using shell script in CI with no avail.
Any direction will be helpful.
As per npm-version docs the command will fail if the working directory is not clean. I can see from your error log that the package-lock.json file is modified, causing the npm version command to fail.
In order to fix this, either commit the package-lock.json file or use the force flag like this
npm version patch --force
Related
Consider the following builds:
3rd build without npm cache
3rd build with npm cache
These two repositories are almost identical, with the only difference being the latter repository caches npm via the setup-node GitHub Action, whereas the former one does not. In other words, the only difference between the repositories is at the .github/workflows/main file:
name: Build Pipeline
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- uses: actions/setup-node#v2
with:
node-version: '11'
# Following line is present only on the latter repository
cache: 'npm'
- run: npm install
- run: npm run build
Although the build at "setup-node-with-cache" successfully uses npm cache (as evident by the output of the Run actions/setup-node#v2 step), run time of Run npm install step is almost the same as the corresponding step of the build at "setup-node-without-cache".
Isn’t the run time of Run npm install step of the build at "setup-node-with-cache" supposed to be significantly shorter than the corresponding step of the build at "setup-node-without-cache", since it is supposed to use the cached npm packages? Am I missing something here?
It really does not seem to be, at least on GitHub Actions. The workaround that I found is caching the actual node_modules folder, even though it is "not recommended". Caching the actual node_modules folder does speed up npm install.
I am a bit new to azure and today I am trying to create a pipeline for publishing npm package to azure artifactory.
The issue is - that after pipeline successfully built, I can see the published package in the artifacts. However, published package is almost empty.
There is only package.json and readme.md. No dist folder at all.
Here is my Pipeline:
# Node.js
# Build a general Node.js project with npm.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/javascript
trigger:
- master
pool:
vmImage: ubuntu-latest
steps:
- task: NodeTool#0
inputs:
versionSpec: '10.x'
displayName: 'Install Node.js'
- script: |
npm install
npm run build
npm publish
displayName: 'npm install and build and publish'
Also, when I build the project locally and run npm publish - the package is published as it should,all files in place.
Is there is something I am doing wrong ?
Finally I found the issue.
The Pipeline definition was actually right, besides one little thing:
versionSpec: '10.x'
Version of the Node was incorrect! The pretty old one. Originally the definition was copied from one of the azure official manuals, so the version was from some really old year.
versionSpec: '14.x'
And build was successful with all files on their place.
Hope that will be helpful for somebody here.
when publishing packages to npm, you need to authenticate with your credential. You could run it successfully on local because of the .npmrc file saved on your computer. When running npm publish on CI, the file doesn't exist, which results in an error. Please try the following steps:
Generate an automation access token from this URL: https://www.npmjs.com/
Go to your repo, and add a file named ".npmrc", enter the content with //registry.npmjs.org/:_authToken={your-token-value}
Notice:
It is recommended to set the access token as an environment variable in Pipeline library.
Please use lowercase words as the package's name in package.json. Otherwise you will receive a 400 error.
I'm trying to push a npm artifact and have it stored in Gitlab in its "Package Repositories" but am having trouble. Have tried a few different ways, with all giving the same error.
The below mostly comes from How do I publish a private npm package with gitlab ci?, and this is my .gitlab-ci.yml file
image: node:latest
stages:
- deploy
deploy:
stage: deploy
script:
- npm install
- npm config set //gitlab.com//api/v4/projects/700/packages/npm/:_authToken ${CI_JOB_TOKEN}
- npm publish
But then gets an error of need auth You need to authorize this machine using npm adduser
I then run npm adduser, but that gets an error of Username: npm ERR! cb() never called!
And here is part of the package.json:
"publishConfig": {
"#foo:registry":"https://gitlab.com/api/v4/projects/700/packages/npm"
},
Another method I try is doing not doing the npm config set..., but instead doing echo "//gitlab.com//api/v4/projects/700/packages/npm/:_authToken=${CI_JOB_TOKEN}">.npmrc, but that gets the same errors.
And yet another method I try is not having npm config nor echo //..., but having this in the .npmrc:
#foo:registry=https://gitlab.com/api/v4/projects/700/packages/npm
//gitlab.com/api/v4/projects/700/packages/:_authToken=${CI_JOB_TOKEN}
But even that has the same errors.
Go through the troubleshooting steps that Gitlab provides.
https://docs.gitlab.com/ee/user/packages/npm_registry/index.html#publish-an-npm-package-by-using-cicd
I'm sure this is a common issue but I can't seem to find a definitive answer.
I have a node application which in order to build requires some devDependencies such as babel. In order to run my tests also requires devDependencies such as jest. But when CI runs in production environment, it obviously doesn't install any devDependencies so I get errors where the package isn't found.
What is the best practice for running builds and tests in prod without devDependencies?
If it helps, I am running my build in GitLab Pipelines:
image: node:8.11.2
stages:
- prepare
- test
- deploy
install_and_build:
stage: prepare
script:
- npm install yarn
- yarn
- yarn build
only:
- master
test:
stage: test
script:
- yarn test
only:
- master
deploy_production:
type: deploy
stage: deploy
image: ruby:latest
script:
- apt-get update -qy
- apt-get install -y ruby-dev
- gem install dpl
- dpl --provider=heroku --app=app-name --api-key=$HEROKU_API_KEY
only:
- master
From this answer,
You will want to follow have your process to the effect of the
following:
First, you need to "install with all dependencies".
npm install
Then do your tests.
npm test
Then "prune" your dev dependencies as below, as detailed in the
docs doing this
"will remove the packages specified in your devDependencies".
npm prune --production
Just mount a Gitlab in digitalocean to keep track of versions of some projects, but now I've read a little about Gitlab I wonder if you can set Gitlab CI so that each time you do a commit automatically make a build of application and if the build is successful can do a deploy to OpenShift.
I think my .gitlab-ci.yml should look something like this:
stages:
- build
- deploy
before_script:
- npm install
job_build:
stage: build
script:
- grunt build
job_deploy:
stage: deploy
But I really do not know if this is as valid and neither tell Gitlab CI must only make a git push to OpenShift repository.
After much reading and searching finally found documentation about this [1], in the end I have resolved some file using the following .gitlab-ci.yml
stages:
- build
- deploy
job_build:
stage: build
script:
- npm install -g grunt-cli
- npm rebuild node-sass
- npm install
- grunt build
job_deploy:
stage: deploy
script:
- apt-get update -yq
- apt-get install -y ruby-dev rubygems
- gem install dpl
- dpl --provider=openshift --user=$OPENSHIFT_USER --password=$OPENSHIFT_PASS --domain=mydomain --app=example
only:
- master
The magic happens with a Travis library call dpl [2] that supports a lot of providers [3]
[1]http://doc.gitlab.com/ce/ci/deployment/README.html
[2]https://github.com/travis-ci/dpl
[3]https://github.com/travis-ci/dpl#supported-providers