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'
Related
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.
I'm using standard-version with conventional commits to manage releases of an app i'm working on, and I'm having trouble with the auto generation of the Changelog.
Basically what happens is that every time I do a new release, it puts in the changelog not only the changes of the current release but also the ones of the previous, like so:
0.0.2
Features
- feature 1
- feature 2
0.0.1
Features
- feature 1
Since I'm in beta this is the command that I run: npm run release -- --prerelease beta
Any good advice on generating a lighter changelog?
Thanks!
Whenever you do a release, you also need to create a tag. For example
git tag -a v0.0.1 -m'First beta release'
then, the next time you run
npm run release -- --prerelease beta
standard-version will only add the changes since the last tag, and you end up with
0.0.2
Features
- feature 2
0.0.1
Features
- feature 1
You have to make sure that you have your tags available locally.
When you run the release.
I believe standard-version makes a git tag when you run npm run release.
I never tagged the repo manually but I see a list of all our releases when I check for tags:
matteo βΈ« aws-amplify-multi-tenant (develop) $ git tag
v0.1.0
v0.1.1
v0.1.1-alpha.0
v0.1.1-beta.0
v0.1.1-beta.1
v0.1.1-beta.10
v0.1.1-beta.11
v0.1.1-beta.2
v0.1.1-beta.3
v0.1.1-beta.4
v0.1.1-beta.5
v0.1.1-beta.6
v0.1.1-beta.7
v0.1.1-beta.8
v0.1.1-beta.9
I'm struggling to find a way to auto increment my package.json of my node application. I've understand that npm has a script called version which accepts 3 params: minor,major and patch but I failed to use npm version minor for example to increment to a new version.
I get npm ERR! Git working directory not clean everytime I try to do it.
So what I want to do is the following:
I have a node app with a package.json file and the version of it start at 0.0.1.
Working on a new feature or bug fix or anything, then I'm creating a new branch and want to push my changes to git.
Now comes the struggling part:
At this point before the commit I guess I'll have to inrement the package json. How do I increment the value automatically when pushing to git?
As I said now it will be version 0.0.1 like :
{
"name": "App name",
"version": "0.0.1",
...
}
And with the new commit, let's say this is a minor release, it should be :
{
"name": "App name",
"version": "0.0.2",
...
}
Also this app will not be published on NPM package repository, so I won't need npm publish.
Minor addition - you can just skip Git version tagging like so:
npm version patch -git-tag-version false
This will also work if you have uncommitted changes, and won't do anything but increment the version number in your package.json.
First of all thank you for the help.
Second the error I got was because I had uncommited files in the branch I was in. To fix that error, I've did git add and git commit before npm version and this steps let me use npm version patch command and increment the package.json file version to 0.0.2 how I wanted.
As #Erick Ruiz de Chavez pointed out in comments above npm version is indented to publish the package on npm but I've used it to sync my Github release version to the package version in the package.json with the help of git push && git push --tags command.
Please check my NodeAutoVersionPush script.
It's a script using Visual Studio Code API to auto set the new version then do commit and push with a keyboard shortcut.
The new version is based on current date and total commits.
But you can easily tweak the code to your preference or for any other language.
I am trying to update my git repo during the GoCD build. That means that because Go sees another change it triggers another build.
Is it possible to stop the re-triggering of the build?
Background:
I am building and publishing npm packages and I want to automatically increase the prerelease version so I don't have to remember it.
My pipeline looks essentially like this:
npm version prerelease --no-git-tag-version
npm publish
git add package.json
git commit -m "Bump prerelease version"
git push origin
This will update the version in git if the publish succeeds but also triggers another build since Go is polling.
Configure your CD/CI tool to build only when there is a commit to a specified branch or you can probably create a new branch called "pre-release" and configure CD/CI not to build when there is a commit.
Once this configuration is done in the CD/CI tool
npm version prerelease --no-git-tag-version
npm publish
// fetching for other branches
git fetch
// Switching your branch
git checkout pre-release
// Finally committing
git add -m "Your commit message"
git push -u origin pre-release
I hope this works out for you :)
You can configure your stages in your pipeline to be triggered manually, for example, if you where setting up your pipelines as code, in your ${pipeline_name}.gocd.yaml.
- deploy-to-next-stage:
approval: manual <-- You need this!
jobs:
deploy:
tasks:
...
This may help as you could run an automated deploy to a development stage and then manually push successful builds to the next stage (pre-release perhaps). In this way, your builds that worked would not be effected by new builds being triggered by a push to your repo.
Or you could put this on your first stage and your entire pipeline would not be triggered by the push to the repo, but instead by you heading into the GUI and triggering it yourself.
There are solutions to increment the version number in different application. Cocoa apps have agvtool and maven has the maven-release-plugin which increments the version number on releases. Are there similar tools for nodejs?
I think such a tool seems excessively heavy-handed when the only thing you need to do to increment the version number in Node.js is something as simple as:
sed -i 's/0.1.2/0.2.4/' package.json
Will change the version for your Node.js package?
If you're talking about something that will deploy your code when you explicitly mark a new version, I'd be more inclined to use git hooks and write a script to detect when a git tag is created and then start the deployment process.
You could use the pre-applypatch hook to detect when a tag is being created to run the sed script listed above and run npm publish for you automatically, but again, I don't see the point of having a heavyweight tool handle all of that when it's a simple script away (and said script could be written in Node.js, too!)
I think the most correct answer is to use npm version.
For example, to increment the major version of your package:
npm version major
This will increment the major version of your package and if it is a git repository it will also commit that change and create a tag of the same name of the version.
Follow up with:
git push
git push --tags
grunt-bump provides version bumping, as well as git tagging/commit/push. There are similar packages for other build tools such as gulp-bump.
Similar functionality is also now available with npm version, but with fewer configuration options.