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
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 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'
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.
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?
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.