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.
Related
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
Here's the scenario: I have a TeamCity "master" build that aggregates the results of other 11 builds.
I'm using snapshot dependencies.
This works fine in normal scenario.But in case, any of the dependent sub build fails and master build is triggered again then all 11 dependent builds get triggered.I want only failed build to be triggered not all.
Is there any way to achieve this??
In TC 8, some settings will interfere with build reusing. From the docs:
Some settings in VCS roots can effectively disable builds reusing.
These settings are:
Subversion: Checkout, but ignore changes mode
CVS: Checkout by tag mode
Perforce: Checkout by label set to Client instead of Client mapping
Starteam: checkout mode option set to view label or promotion date
(source: https://confluence.jetbrains.com/display/TCD8/Snapshot+Dependencies)
Normally, if the source code for any of the 11 dependent fields has not changes ,they will be queued but will just silently go to success
In case you just need artefacts from the previous builds, you can try setting up artefacts dependencies instead of snapshot dependencies. That way you can rerun an intermediate target if it fails and still continue for the rest of the chain. By the way if you are setting artefact dependencies you also have to add "Finish run triggers" on the targets
Also, when setting snapshot dependencies, there is an option "Do not run new if there is a suitable one". Please enable it to see if it solves your problem
I have several projects that produce NuGet packages that I publish to an internal server. We're using semantic versioning, and using tags in our Git repository to control the version numbers.
I'm tagging like this:
git tag -a v1.0.0 -m "tagged"
And, during the TeamCity build, I run git describe --long, which produces an output like this:
v1.0.0-0-ge9c047d
The fourth number in the output is the number of commits after the tag. The 0 here means that no commits have been made since the tag. I use these first four numbers as the version number (and, incidentally, the entire string as the AssemblyInformationalVersion).
I have TeamCity package and publish a NuGet package, but here's where it gets sticky. I only want to publish tags, never commits after tags (because the version number in that case would be wrong, possibly VERY wrong).
I've tried setting the "branch specification" in the VCS root to "+:refs/tags/*", which causes all the tags to be built, but TeamCity also insists on building the "default branch" as well. If I set the "default branch" to something that doesn't exist, I get an error.
I've thought about ending the build early if a particular build isn't a tag, but I can't figure out how to do that without FAILING the build, which isn't what I want.
How do I cause one or more build steps to only run for new tags, and not regular commits?
If you are using TeamCity 8.x, there is now support for VCS branch triggers, which would allow you to not run builds from the default branch.
Try this:
Leave the Branch Specification in the VCS Root as "+:refs/tags/*"
Change the VCS build trigger rules to:
+:*
-:<default>
This will filter out the default branch from the trigger and you won't need to cancel the build.
I'm migrating continuous integration system from Teamcity to Jenkins. We have a single svn repository for all our projects like this:
project/dev_db_build (folder)
project/module1 (folder)
project/module2 (folder)
projets/pom.xml
For building db on CI server I use url project/dev_db_build and can pol this url to trigger builds when there are changes.
For building application I use url project/ So if I poll it and there are changes to dev_db_build application build should be ignored and triggered after db_build as successful.
In teamcty I used "Trigger patterns" for this. But in Jenkins there are so many triggering plugins https://wiki.jenkins-ci.org/display/JENKINS/Plugins#Plugins-Buildtriggers - I looked into some of them and have not found suitable.
Ideally, you should use a post-commit hook as suggested by #Mike, rather than polling. Otherwise, when configuring the Jenkins job, under 'Source Code Management' with 'Subversion' selected, there is an advanced button. Clicking this reveals an number of options, including 'Excluded Regions'
If set, and Jenkins is set to poll for changes, Jenkins will ignore
any files and/or folders in this list when determining if a build
needs to be triggered. Each exclusion uses regular expression pattern
matching, and must be separated by a new line.
/trunk/myapp/src/main/web/.*.html
/trunk/myapp/src/main/web/.*.jpeg
/trunk/myapp/src/main/web/.*.gif
The example above illustrates that if only html/jpeg/gif files have
been committed to the SCM a build will not occur. More information on
regular expressions can be found here.
In your case, you would set 'Excluded Regions' to something like
/project/dev_db_build/.*
Do you have the ability to edit your Subversion hooks? Instead of having your Jenkins server poll SVN, I would recommend that you have SVN call Jenkins via a post-commit hook to automatically kick off a build upon developer commit. This has the effect of lessening the load on both the Jenkins and SVN servers as well as not having a waiting period of however long your polling interval is before a build is kicked off.
Right now, TeamCity is creating 2 sets of artifacts each time I do a successful pre-tested commit, one when it builds the solution with my local changes against which to run the tests, and a second time when it gets triggered by the VCS repository change.
How can I prevent it from creating artifacts for its build-to-test before commit?
Check build.is.personal system property or BUILD_IS_PERSONAL environment variable to be defined.
Use a different build configuration for the VCS triggered build, one that doesn't have any paths configured for saving Artifacts.
Go to the Administration page and copy the existing build configuration.
Under "Build Triggering" on the original configuration, disable "Enable Triggering when files are checked into VCS"
Under "General Settings" on the copy remove everything from Artifact Paths