We are in the process of migrating from npmjs to GitHub Packages for our private npm packages. To try and smooth this process, I am trying to have our CI process publish packages to both registries while projects make the switch. We've been using pretty vanilla semantic-release to do our versioning/publishing and I'm trying to preserve that but keep getting stuck trying to publish to more than one place.
My first attempt had a workflow that went:
build/test/etc.
npx semantic-release with NPM_CONFIG_REGISTRY={github} and appropriate creds
npx semantic-release with NPM_CONFIG_REGISTRY={npmjs} and appropriate creds
This results in an error in step 3 because semantic-release tries to re-tag/release to github and fails because it already did that in step 2.
My second attempt was:
build/tests/etc.
npx semantic-release (same github settings as previously)
npm publish with npmjs settings
This works if step two did a release - step 3 pushes the just-created release to npmjs and all is well. However, if step 2 did not do a release (typically because there were no commits that should cause one based on semantic-releases rules), step 3 ends up trying to re-publish whatever the previously released version was, resulting in an error.
Googling for topics related to "publishing to multiple registries with semantic-release" doesn't seem to yield much, so I'm also wondering if I'm just going about this migration the wrong way. Alternative suggestions welcome.
Related
we probably have a really specific case. We are using
Private NPM registry on Azure DevOps
Yarn v1
Semantic-Release Monorepo (containing multiple packages. I think if it would only be one package, it would be ok)
Everything works fine and as expected, we now want to update to Yarn v3, but this is where the issue arises
semantic-release, per default, uses npm to create releases. It also uses .npmrc, if available to authenticate against the private registry.
However, since yarn v3, the .npmrc is not supported anymore, so it doesn't exist and also, while npm creates the same yarn.lock as yarn v1 it doesn't create the same yarn.lock as yarn v3
So, now we are facing the following issue
When running our pipeline our semantic-release fails, because it is changing the lockfile (we tested this locally, and the lockfile is indeed changed), because semantic-release internally uses npm with a plugin and this plugin which formats the yarn.lock to an outdated format and then fails to deploy multiple packages
To solve this, we found the following library https://github.com/dmeents/semantic-release-yarn/
however, this library requires that we set an NPM_TOKEN so yarn can authenticate with it. With the npm plugin, it checked for an .npmrc and used this one to authenticate, but since this doens't exist anymore, the new package searches for NPM_TOKEN.
However, I have not found any way how too get NPM_TOKEN from Microsoft Azure DevOps. In the .yarnrc.yml we are using the npmAuthIdent which you can see here has the wrong format
Defines the authentication credentials to use by default when accessing your registries (equivalent to _auth in the v1). This settings is strongly discouraged in favor of npmAuthToken.
npmAuthIdent: "username:password"
Defines the authentication credentials to use by default when accessing your registries (equivalent to _authToken in the v1). If you're using npmScopes to define multiple registries, the npmRegistries dictionary allows you to override these credentials on a per-registry basis.
npmAuthToken: "ffffffff-ffff-ffff-ffff-ffffffffffff"
https://yarnpkg.com/configuration/yarnrc#npmAuthIdent
As I see it, there are 3 possible solutions
Migrate back to yarn v1 (Least preferred solution)
Find out how to get such an npmAuthToken using Azure DevOps (Most preferred solution)
Create our own plugin for semantic-release to suppoort yarn in combination with Azure DevOps
Do you have any idea how to solve this or maybe someone already faced this issue?
I have a Bitbucket pipeline, for a StencilJs project which has a first step where i bump the version number in package.json using npm version patch. This works fine, and i get it pushed back to the repository and all, without problems. Next step in the pipeline, is where i build the StencilJs project. The problem here is that the project is built using the old version number, not the one i bumped it to. So the original version in package.json may be 1.0.3. Step one bumps the version to 1.0.4 and pushes it to repository. I want the next step to build the components using version 1.0.4, but it doesn't. It still uses 1.0.3 when building.
Anyone how knows how i can make the build come out with version 1.0.4?
Kind regards,
Lars
I made it work by putting npm version patch into the same step as where i am doing the build.
The problem is probably that your pipeline keeps running on the commit prior to you tagging and committing back. You could set up another pipeline to do the Stencil build that triggers when a new tag is created.
To avoid infinite loop i had to add [skip-ci] in the version patch commit message
My pipeline look like this:
pipelines:
branches:
master:
- step:
name: Patch version
script:
- 'v=$(npm version -m "%s [skip ci]" patch)'
- 'git push origin ${v}'
- 'git push'
In another project I managed to setup Artifacts for NuGet and it worked better than I expected. I was able to publish my private NuGet package and use the artifacts to get the private package along with the nuget.org too:
Now I want to do the same for npm.
So I set up my artifact and then went to my pipeline and updated the task:
Notice how there is no "Use packages from npm" flag.
Anyway, I thought it would work without that flag and I ran my pipeline and I got this error:
10691 error 404 '#babel/helper-validator-identifier#7.9.5' is not in the npm registry.
Which is really annoying. It's erroring out at the first package it searches for.
I tried to be smart and had two tasks for installing packages. One for my artifact private package and the other using npm defaults but if it errors, it doesn't try to get the next package :(
Does anyone know how I can get around this.
PS: I should stipulate that I don't want to add a .npmrc file to my project. There are many many many projects that use this private package and it would be a massive ballache to have to add that file to them all.
To publish an npm package the version number in package.json is used. For it to succesfully publish a unique number must be added. Otherwise, in the Azure pipeline the build will give an error or warning and then it will not publish.
Is it possible to conditionally run the npm publish task which only runs if a certain tag is present in the commit?
A similar question has been asked on: https://learn.microsoft.com/en-us/azure/devops/pipelines/targets/npm?view=vsts&tabs=yaml
I have a query on how others accomplish this and what, if any, the best practices are. I have an application that comprises three packages and they are setup in Bamboo for CI/CD.
The issue I am experiencing is that of how to automate the update of the package version on each build, e.g. npm version patch to bump the package version.
What I would like to know is how other accomplish these, I have thought about manually running npm version patch but that is not ideal and would be prone to errors (eg. forgetting to run this). I had also thought of adding a step in Bamboo to run npm version patch during the build but Bamboo clones the repository with out remotes and there unable to commit the change, otherwise every build would be the same version and still no better off.
An example is that we have a package which is an Electron application and when the build runs generates an MSI and .yml file for the auto updater, without incrementing the version the MSI will always be the same version and therefore the auto update would not work.
So what are the strategies for automating the version of an npm package for each build? What do others do in similar situations?