I have a Jenkins server running on a Linux box and some Java projects in BitBucket. I have a web hook in place to trigger a build on my Jenkins server when I commit changes to BitBucket. The triggering of the build is working fine and is doing a maven release prepare and perform. The problem I have is that when the version number in the pom is updated and pushed back to BitBucket another build is triggered and thus we end up in a loop.
I have experimented with using the SCM Skip plugin to try and break the loop. In the pom.xml release plugin section I set scmCommentPrefix to [ci skip]. This worked in so far as it stopped any further builds but it then would not do a build when I made further changes to the source code.
On investigation what is happening is that when the next build is triggered it is not only looking at the last commit message but all of the commit messages since the start of the previous successful build, which includes the commits from the maven release plugin that now contain [ci skip]. What I need it to do is only look at the very last commit message, if that contains [ci skip] then it should not do the build otherwise it should proceed.
Thanks for the help.
Andrew
Related
I'm on a project that uses Mulesofts Anypoint studio for API development. Anypoint studio uses Maven to build its projects and handle versioning. Currently we are using a Git-flow branching model without release branches (feature/development/master) and the CI tool is Jenkins. We want to migrate to Azure-DevOps with Trunk-based branching.
The current git-flow CI set-up works as follows:
Merge feature with Dev
Jenkins triggers on Dev and builds a package with Maven
Jenkins deploys the package to D
Test your API on the D, if its good manually trigger Jenkins release pipeline
Jenkins will merge dev with master
Maven creates a release; creating a package (e.g. v0.1) and prepare the next development iteration (v0.2-SNAPSHOT) in master
Jenkins Deploys the package on A and P
Merge master back into Dev
So we have 2 separate pipelines here: dev and release. I'm hoping trunk-based development makes this process simpler by reducing it to one pipeline that is triggered by merges into master. But I don't know how to handle the versioning with Maven here.
This is what I have in mind for the Trunk-based (feature/master) pipeline:
Merge feature with Master
Azure pipelines triggers Maven release
(!) Maven takes the 0.1-SNAPSHOT version and creates a 0.1 release version and puts it..where? in a release branch?
Maven then creates the next working version 0.2-SNAPSHOT on the master branch
(!) this would trigger Azure pipelines again, creating a loop
Anyone have experience with Trunk Based development with Maven solve this? I would actually prefer to do it without a release branch because the released packages are already providing the release-branch functionality.
At first glance this answer seemingly solves my issue, but it just ignores the issue by going around it and just using a hash.
I have just hit a roadblock and would really need some insight from someone who knows the maven-release-plugin. I am trying to use the plugin for operating with my pom file, but without having it touching/committing to the main branch, but to a separate branch so that I can later on PR from there and get the review+approval required by the branch protection policy in my repos.
Context
We use github, and the company is enforcing a new branch protection policy in our main branches for security reasons mainly.
I have been using a jenkins pipeline for releasing and delivering my code which in turn, uses the maven-release-plugin for tagging the repo, and switching the version in the pom.xml, etc.
When using github's branch protection, the release plugin cannot do the usual operations, because it cannot push straight to the main branch.
My research
I found out that the plugin supports creating a branch in the process of releasing, that would be exactly what I am looking for. So, I built the environment for trying this out:
GitHub repository
Maven project
and started running some tests. The closest to being successful, was this line (version number is not important):
mvn --batch-mode release:branch '-DbranchName=release-v1.2.1' -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false
I started with the version in the pom set to the value of the version I am releasing (it is not great, but I am willing to make that commit myself). I have checked the release:prepare docs but found nothing that would help me achieving my goal.
My question
Is there any way of telling the plugin, not to make any commits to the original branch, so that it does not get rejected by the branch protection?
I always get at least a commit to the main branch like this one:
* 934af86 2020-04-27 | [maven-release-plugin] prepare branch release-v1.2.1 (HEAD -> master) [Commiter Name]
I know it's late to answer this but I just had the same issue and maybe someone else will search for this as well.
My configuration:
Jenkins
SCM Manager (Sonia)
Git master repo restricted for PRs only
What I end up doing was checking out to new branch and do the release from there. In my SCM-Manager I removed all priviledges for this branch from other users except for jenkis to protect it from being written directly.
So in jenkins project configuration I have set "Branches to build" to "*/Master". Then I added "Check out to specific local branch" in "Additional Behaviours". In branch name I have put "master_release". Your branch should be shown when you do release for the first time.
Since this was first release I will update this answer if I encounter any issues on next iteration but from my perspective it should work.
I have a Bamboo CICD pipeline using maven build and release. Have created a trigger of type "Repository triggers the build when changes are committed" and my repository is BitBucket.
Whenever code is checked in or if there is a change in my repository, build pipeline is getting triggered. Last step of my build pipeline is maven release which updates and checks in the pom file. This check-in is in turn invoking the pipeline resulting in a loop. Is there any way this loop can be stopped by not invoking the pipeline for pom file changes checked in by bamboo?.
Configure the plan, goto the Repositories tab and select your repository (or linked repository).
Scroll down to the bottom and expand Advanced Options.
There is a dropdown for "Include / exclude files", select "Exclude all changes that matches to the following pattern" then a textbox will appear underneath "File pattern" where you can specify a regular expression to express your pom file.
Link to pattern examples
Maven release checks in the files with commit message "[maven-release-plugin]" and Bamboo plan ignores commits starting with the specified pattern. I had earlier updated the maven release commit message to satisfy my commit hooks hence Bamboo plan was always getting triggered. Have now updated the commit hook to accept the maven commits.
I want some "Maven with Mercurial release" knowledgeable opinion.
I already saw this thread and a few others.
We want to be agile and fast. We want to build once. Not one build for testing and one for release.
We have setup a continuous release process where we do the following:
Jenkins checks for SCM changes on "server" repository (every 30 minutes). Also can be triggered manually
Jenkins clones "server" repository
Jenkins increments version in pom (example: 1.0.1 -> 1.0.2). NO Snapshots
Start build, package, automatic deployments and tests
If all is good, commit changed pom, tag and push back to "server" repository (merge if needed)
Release good version to a "releases" system, where it's available for QA for further testing
Developers will pull back changes from "server" repository and get new versiond poms
If a hot fix is needed for a good release
A developer will clone the relevant tag from "server" repository
Do the fix, push back to a "server+fix" repository
Jenkins will build as before
If good, the fix will also be pushed to the main "server" repository
We found this process to be very quick and clean.
I want your opinion on the flow, with ideas to improve. Remember - Fast, Continuous and Build once.
Thanks in advance!
+1 to the no snapshots rule. I think its all good.
Release good version to a "releases" system, where it's available for
QA for further testing
What is the "releases" system. Is it a maven repository? Does a new build automatically get deployed to the QA environment? How does it pull from the respository? You could pull a jar from a maven repo using dependency:get. But if want to make use of infrastructure automation tools like Chef or Puppet for your deployment side, you'd be better off publishing rpms to your maven repository (publish using the maven-rpm-plugin and enable pulls with the nexus-yum-plugin for example) or simply setting up your own yum repository.
I've started using TeamCity personal builds, via the new Git remote run feature in TeamCity 6.5. Doing a single build works fine; I have a project that compiles from source, and I gave it a Branch Remote Run trigger.
However, it looks like TeamCity only triggers the one project that has the Branch Remote Run trigger applied. I have several unit test projects, set up in a chain with Finish Build triggers, and none of these get run. Furthermore, if I try to start a custom build of one of these unit test projects, I can't use the artifacts from my personal build: I can only pick artifacts from one of the 'official' builds.
Can I get TeamCity personal builds to work with build chains?
With the setup that you have (snapshot dependencies and finish build triggers), you can achieve build chaining by submitted your personal changes to the builds you are looking to trigger. For example, if you have projects A and B where B depends on A - run the remote build against project B and A will be triggered first and B will be added to the queue. Both of these builds will have your personal changes.
If you are using the TeamCity Visual Studio plugin you can select which builds you want to send your changes to and you just need to tick the box for B instead of A.
The finished build trigger won't be fired, but the build chaining means that A must be built first.
More info - http://confluence.jetbrains.net/display/TCD7/Build+Chain
(You have tagged TeamCity 6.5, but 7 has now been released so I have included the documentation for the newer version)
I suppose you should setup your chain not with Finish Build trigger, but with "Snapshot dependencies" feature of TeamCity. And, setup artifacts dependency basing on the snapshots.
Please read about snapshot dependencies in TeamCity here.