I am following standard gitflow, and I have different environments for testing the dev builds, and release builds. master goes to production.
I also have my JS app divided into multiple private npm modules which goes into private npm repository.
Q1
Is there any way I can version my npm packages, against the branches they are built on in a standard way?
What I have tried is, I have prerelease pre-ids added to the versions. like
1.0.0-rc.0 //for master
1.0.0-beta.0 //for release
1.0.0-alpha.0 //for dev
But if I create a feature branch from master, it contains the master's version. When I try to raise a PR from it to dev, then it shows conflict, since dev has -alpha.x in its version. To resolve the conflict, I'll have to consume the target branch's versioning. Same issue when it goes for merging on release branch too.
And when it comes to merging to master, the release version (one with -beta.0) completely replaces the master.
So it becomes like this: on master,
| It was | After Merge | After version bump |
| ------------- |:-------------:| -------------------:|
| 1.0.0-rc.0 | 1.0.0-beta.0 | 1.0.0-rc.0 |
Ideally after the version bump i would have wanted it to be 1.0.0-rc.1
Is it possible to keep package JSONs out of versioning.
Q2
How do I control the versioning in the package JSON of the application where these NPM modules are consumed? It too is on gitflow and feature branching model, and I would want that the App, when it is building on dev branch, it builds with artifacts that are published from their respective dev branches.
Honestly, I might be misusing gitflow too, but as of now, too confused to figure out where I'm going wrong.
Any Help will be appreciated.
Thanks in Advance
The way I solved it is,
//${buildNumber} and ${branch} are available as env variables in the build agent(at least available in jenkins/bamboo)
tagversion="1.0.0-${branch}.${buildNumber}"
echo $tagversion
npm version $tagversion
so my builds are created and published as
1.0.0-master.1 //for master
1.0.0-release.1 //for release
1.0.0-dev.1 //for dev
You can user merge strategy as ours for package.json file in all branches. Details steps as below:
Configure merge.ours.driver as true
git config --global merge.ours.driver true
Add .gitattributes file on each branch
Add .gitattributes file with below content on each branch as below:
echo 'package.json merge=ours' >> .gitattributes
More details, you can refer last part (Merge Strategies) in Git Attributes.
Until now, for most situations, package.json file won't be overwritten during merge.
Note: pakage.json file will be overwritten for recursive merge. When merging changes from branch1 to branch2, if the file package.json is only changed on branch1, the merge commit will keep the package.json file with the version from branch1 by recursive merge strategy.
Such as on master branch, the version 1.0.0-rc.0 has not changed; while on release branch, the version has changes to 1.0.0-beta.0. When merging changes from release branch into master branch, the version will be 1.0.0-beta.0 (as you mentioned).
So for recursive merge situation, you need to manually change the package.json file version after merging:
# On the merged branch, as master in above example
git checkout head~ -- package.json
git commit -m 'use the original package.json after recursive merge'
Related
Has anyone experienced how to add an existing NodeJS API to an existing (Angular) Nx Monrepo?
Unfortunately the manual doesn´t help me so much
https://nx.dev/migration/manual
The process of migrating a repo into your mono repo requires a few manual steps. I think there would not be a simpler way to do it.
Assuming your node project does not share files with your current monorepo, this should be the steps:
on your node repo, create a branch 'to-monorepo' and in it, move all the files to folders that match the nx folder structure and push the commits to it.
remove your package.json file (we will later merge it with the monorepo's one)
once the folders match the nx folder structure, time to merge into the monorepo. From the monorepo add the remote of the other repo
git remote add node-repo <your git repo's node url>
at the monorepo folder, checkout your master
run a pull to make the node repo branches be available in the monorepo
git pull
create a new branch 'merging-node-repo' on your monorepo.
merge the branch node-repo/to-monorepo into your merging-node-repo branch, preserving the history:
git merge node-repo/to-monorepo --allow-unrelated-histories
push your new branch (all the code and its history will now be listed in this new branch)
remove the remote node-repo from your local monorepo configs
git remote rm node-repo
manually merge all the node repo's original package.json file dependencies into the monorepo's one, and run npm install from the monorepo. This way your package-lock.json file is updated. Once you are done, create a commit and push it.
this last step is more tricky. You have now to manually update the monorepo's config files to allow nx to start managing it. This is where the link you had in your question might help. Once you are done, create a commit and push it.
With these steps you can then merge your merging-node-repo branch into master.
I recommend you to create a separated nx workspace with a nodejs project on it. This helps you with having a baseline for all the necessary nx configurations and dependencies.
You might want to make sure your project works via nx commands from this separated workspace; this way you will have a better chance of getting configurations of your monorepo right.
Hopefully this gets you started.
Here is a solution that I wrote and used to import multiple repos into a single monorepo, under whatever subdirectories are wanted, while maintaining commit history:
https://github.com/marcuswestin/monorepo-merge
I've also found two other scripts that look like they might work, but I haven't tried them:
http://choly.ca/post/git-merge-to-monorepo/
https://github.com/ksindi/monoreaper
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 would like to know how to manage dependencies updates between branches.
Example:
Working on branch A with a module in v3
Updating the module via npm on branch B
Working on branch A again
Since modules in node_modules are the same between branches, the module is still in v4 when back on branch A.
This generates an error because a function doesn't exist in v4 anymore.
Is there a way to manage this without having to re-install the correct version each time we switch branches ?
I've done few searches before posting but none of them helped me.
I hold a git repository for my personal website, and I have a small problem when checking out one of its branches. There are 3 branches for different tools or frameworks : the former master branch, which acts as the current version of my website, & the Elm and Vue ones, that I'm working on at the same time. Each of these branches contains a package.jsons file and so a node_modules directory. My problem is : after checking out a branch, I have to 'yarn install' my packages to run the dev mode or build the app (with webpack), because of all the conflicted packages hosted in the same directory on different versions I guess.
It's a bit tiring to reinstall the required packages each time I checkout a branch. Moreover, I have then to commit the updated yarn.lock file.
So I am wondering if there is a way to create a specific node_modules folder or sub-folder, one for each branch, in order to have "scoped" directories. Or should I better separate this repo in 3 repos ?
I hope I am clear about this problem.
Thanks for reading !
You can commit node_modules so git will switch them on git checkout.
Or you can create separate worktrees. Checkout different branches in different worktrees and don't switch branches afterwards.
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.