TeamCity 2017.1 (build 46533)
Plastic SCM version 5.4.16.814 Doobie Brothers - China Grove
I have configured an include Trigger rule in TeamCity triggers to include changes from a particular VCS root and a specific file path.
+:root=testbuild_VCSTestBuilds:Utilities/**
The rule should only trigger a build if it detects changes within the utilities folder and ignore any changes in any of the other folders.
Having set this rule once a change is made it is recognized as a pending change - but no build fires off.
Have I done something wrong or is there an issue between TeamCity and Plastic SCM
On the VCS Trigger dialog where you're setting the trigger rule, make sure you have the appropriate branches included in the branch filter.
Related
I am using teamcity to build my Unity3d projects. When I am selecting branch in custom build or when build is triggered from "not master branch" git performs clean, and it removes my Library folder. I need to persist this folder because it is a cache that builds a huge amount of time. When I stay on master, everything is fine and this cache is reused. How can I do this? I want this folder to be shared between my branches.
I tried to create multiple VSC roots, but it copies my repo for every branch. I also disabled all "clean" options that I found in settings. But nothing helps
You could try one of these:
In VCS Root settings you could set Clean Policy to Never. It sets whether and when TeamCity should exec git clean in working dir. Default value is "On branch change" which I guess is your case. But it means that you should manually clean your working dir from build artifacts. For more information see here
You could use Unity Accelerator
You could backup your Library folder in the end of every build and restore in the beginning of the next one
I want to accomplish following via teamcity in my CI box.
Master branch commit : Build and Release
Beta branch commit: Build and Release to Crashlytics
All other commits to any other branch: Build
(side note since most of our development branches may or may not contain a prefix, it makes it difficult to use "feature-*" branch naming)
Following this question Select Git branch for TeamCity Build
I have created a Configuration Parameters in my project settings
and then
my VCS root settings
Then I created a build template
When I created builds I made sure branch name is correct
I have also tried to edit Triggers
How ever this is not working because when I push a commit to Beta branch
I think because of ref/heads/* default build is running all the branches
and Beta and Master displays "Pending"
How can I correct this?
I solved the problem by talking to other developers and making sure that all development branches uses a prefix, in this case XAAI-
then in my VCS root settings
for triggers in each build configuration I make sure it only is triggered when that branch is checked in.
for example for QA (Betabuild)
this is the tricky part , for Development branches I had to give an empty parameter, I dont know why (maybe because something needs to check default branch which is supposed to be ref/heads/) but whatever the reason it is working.*
and then finally whole thing looks like this
That pending thing is still annoying but , I think at least it is working as I envisioned now.
If you want your builds to only trigger automatically when the default branch is pushed to, you can add a branch filter to the trigger like so +:<default>.
This is dependent on the assumption that you have setup the %BranchName% parameter in each build configuration correctly. IE, for your Default build, make the %BranchName% parameter = master.
As a side note, you will still see all pending changes for each branch, but the trigger will only run when you push to your default build if you add the branch filter. If you want to get rid of the pending changes for each branch, you'll need to setup your vcs root specfic for each configuration to filter out the branches all together.
We have over 100 build configurations in Team City, and I've come to realize over the past few months that these assets are just as important (if not more so) than the actual project assets (code, config, etc) we are delivering.
To that end, I know TC provides it's own build configuration version control but to me that seems a bit low on features - for example if a build stops working it would be really good to be able to diff the actual XML build configurations in my favorite diff tool rather than rely on TC's built in one, or to be able to view differences across a longer time frame than simply against the previous state.
Obviously this can be handled manually by extracting the build definition and committing, and then applying self disciple to always do this when you change the definition. Can anyone suggest a more joined up approach? We're using TeamCity Enterprise v8.0.5
Can you upgrade to TeamCity 9? TeamCity now has built in support to sync the build configurations to Git or Mercurial.
https://www.jetbrains.com/teamcity/whatsnew/
https://www.youtube.com/watch?v=zTLeCrdxGIw
As an interim solution before you upgrade to TeamCity 9, you could write a scheduled job to run every 10mins (or even every minute) and automatically commit the changes to a new repository. I'd use a new repository so TeamCity doesn't ever try and trigger off the commits.
I don't know what OS or VCS you are using, but you'd just need to commit all XML files so you get project-config.xml, build type XML, and plugin config, you don't want .properties files as the build number files will change after every build.
<TeamCityData>/config/projects/**/*.xml
If you are using Git you could easily just init a repo in the projects directory, add a .gitignore for anything other than *.xml, and run git add . and git commit -m "Build configuration settings were edited" as a scheduled job.
there's an "issue" (actually a nuisance, but a major one) with our development process.
We've setup a good continuous integration-deployment-delivery pipeline; basically, our process is like that:
New development happens on the default branch (we use Mercurial, but git would have the same issue); usually we develop just one small improvement there;
Once the improvement is ready and tested (something that usually happens twice or three times a week, our cycle is pretty short), it's merged into the release branch (which actually stands for release candidate), it's tested again in a production-like environment and if it passes all our testing it's pushed to the production environment.
If we need to make a bugfix, we do it on the release branch, we test it and then push it to the production env.
An artifact (usually an RPM package) is built from each branch; when there's a release in production, the very artifact from the release branch is promoted to our public repository. There's no branch for the production environment, because we usually don't need it (there's a very short timespan when something it's on the release branch but it's not in production; code doesn't linger there unattended).
In this context, there's a small issue for us.
In order to distinguish packages, we usually set version to 1 for packages on the release branch, and 2 to packages on the default branch. Our CI system then adds its build number, so we've got packages like oursoftware-1.0-build37 for release and oursoftware-1.0-build902 for default. Such version is written either in our .spec file or in our pom.xml files (or other files for different softwares, like .gemspec or simila)
Whenever we want to put something in release candidate, we merge the default branch to the release branch.
What happens there? the version gets merged as well. So after each merge we need to get back at the file containing the version and put the old version in them. We should need to do it just once (Mercurial does not try to re-merge things that were already merged) but whenever we need to do a merge from release from default (e.g. in order to merge a fix done on release to the dev branch) the problem rises again.
I'd like some advice on how to prevent this problem completely; how do I set versions outside of my branches? I sometimes actually need to change them (e.g. I want to change from 1 to 2 on release and from 2 to 3 on default) and I wouldn't like to hardcode them in our CI system, I'd like some system which is "outside" the scope of branches and it's kind of "global" for a repository. Or I would need something like "ignore modification for some files".
In many situations I actually need versions in my files as well; for example I cannot omit version info from a Maven pom.xml file or from a .gemspec, otherwise it won't work when developing.
Thanks,
Well, I see 3 4 a lot of possible solution, more or less "native" (random order without priorities and own personal preferences)
Instead of "Monolitic $DEVEL branch" you can use "Branch Per task": in this case file with (hardcoded) version-info will not appear as mergeable file (TBT!)
Branch-specific version change can be moved from (permanent) changeset of branch into patch of MQ (as results - versions /and files/ are identical across branches, permanent default changes have to appear as result of applying patch)
Files with version-info doesn't contain hardcoded versions, they are more "templates", than "data", and real data appear as result of some preprocessing inside build process (you know transformation-rules and can code it)
You can change nothing in developent|deploy process and if version-info files are unique inside repository, you can use trick, similar to merging hgtags (special mergetool for only some files in repo - in your case in must be internal:local special mergetool)
Maybe using just merge-patterns will be OK for you, check Mercurial - Exceptions to internal:local merge-patterns? and Default to trunk version for Mercurial merges? for details and some additional notes+discoveries
How can I write a post_commit (like) plugin that is executed only when a specific branch is commited?.
Right now I have written a plugin in "~/.bazaar/plugins/" directory, but the problem is that the plugin is executing when any branch in the repository is commited.
The idea is to trigger a call to a Continuous Integration server (Hudson) to automatically build the project-job when a revision is commited
Thanks.
There is no automatic way to associate a plugin to specific branch, but you can use configuration files (either branch.conf or locations.conf) to control the behavior of your plugin. So your plugin only should open the branch config and read some option from there, for example:
my_plugin_post_commit = enabled
And if required option is present in branch config then you execute required operations, otherwise your plugin simply exits and that's all.