I have a setup where our code builds to dev every 5 hours on a schedule trigger. This works great, but the downside that the code could sit in teamcity for hours before it triggers and alerts us to a build error.
Is there a way to have a VCS trigger also run the build as soon as its checked in, but passing something to our NANT script to say "just build, don't deploy"?
I know I must be missing something.. is there any way to achieve this?
The only way I could think of was to have an entirely separate build configuration, but that seemed rather wasteful
You can setup a new build with a VCS trigger and then have that build have a env/system variable set that your build script can read to determine whether or not to deploy to dev.
See TeamCity Docs for information around this. I've used something like this in setting up builds before and it works well.
Related
We have a teamcity build, triggered by git, that is doing git integration, sometimes checking into the current branch (it's updating the branch from another source). This obviously creates another check-in on the same branch, and causes the trigger to see it.
Ideally, I'd block the trigger from seeing that second check-in, but I can't seem to find a way of doing that - as what we are checking in is a conglomeration of changes from other sources. I know the last change is from the build system user, but can't see a way of excluding based on the result of the most recent change.
So I built something in the build script, that correctly ascertains we shouldn't go ahead with this build. I'm currently just failing - but this isn't actually an error case. I want to stop the current build without doing any further steps, but I want the result to be green, and everything to be fine. Is this possible? I tried doing the ##teamcity set status, but that didn't work.
I actually "solved" the problem, with a brain-dead but easy hack - I just set a variable "skip", and check it at the start of each subsequent step. Ugly, but for the moment - it works.
You can set a VCS trigger rule (5 Build Triggers) with an exclude rule that will not trigger when the build system user commits to your repository. The exclude rule would look something like this:
-:user=TeamCityUser
Hope this helps!
You can filter out triggers by commit messages. When checking-in from the build agent, always check in using a predefined and specific message. Then you can change the build trigger to not fire when that specific message is part of the commit
I’d like to be able to specify that one build project should pause while another specified project is running.
In my case, there is a project #1 that builds and deploys compiled code to our servers, and a project #2 that performs Selenium tests on that deployed code. The tests can take several minutes, and I’d like to make sure that the build-and-deploy doesn’t happen in the middle of testing.
So, I’d like to pause #1 (build) while #2 (test) is running.
Dependencies or Triggers do not offer this option, as far as I can tell. Can this be configured?
There is a request on TeamCity issue tracker TW-3798. You are welcome to vote and watch.
This functionality is currently being developed. For now you can use one of the features provided by GroovyPlugin called StartBuildPrecondition. To ensure that only one build is executed add the same write lock to both of the builds
The way we do this is by restricting them to one build agent. They you are insured that only one runs at a time.
I have an environmental build system which currently has the following environments:
dev
ci
uat
live
Just to be clear when I say environmental build I mean there are a set of properties files for each environment and during the build these properties are used to template project files, so a database server may be "localhost" on dev environment but "12.34.56.78" on CI. So when starting the build you can give it an environment property and it will build for something other than dev (which is the default environment).
Now the CI build works fine and spits out the artifacts correctly, however as the build is CI all of it is configured to work on that environment, and I am looking at being able to trigger a build for live or uat when a CI build succeeds. This would then run the same build but with a different build argument.
Now I noticed there are a few mechanisms for this, one seems to be doing an automatic trigger on complete which could trigger another build, but this seems to require 2 separate build configurations which are essentially identical other than the build argument being "environment=live" rather than "environment=ci". Then there is adding another build step which would be the same as the first but take different argument and output the live artifacts elsewhere, but this would always happen much like the first option.
The final option I could see was to trigger a manual build once I have a live candidate, but it is unclear as to how to set a build argument, I could make a build parameter however it doesn't seem to get pulled into the build script like a command like build argument would.
I will see if there is a better answer, but after writing this I found that using Build Parameters seems the best option, this then can be embedded within your build configuration anywhere using the %environment% (or %your_parameter_here%).
This can then be setup to create a form element for manual builds so you can easily create a build for a different environments.
I have created many build configurations in Hudson for a single solution (eg. Release, Debug, Test)
When I commit something wrong, I receive 1 build failed e-mail for every build configuration.
I would like to receive a single e-mail.
I think if I could to make one build dependent on the success or failure of another, I could receive less e-mails.
How to do that?
BTW: I use MsBuild, Subversion and NAnt
It sounds like you have multiple jobs (build configurations) for the same set of source code that are configured to always build. You could, as someone else suggested, use build triggers to chain these jobs together. However, if all the jobs run on each commit, I suggest combining the jobs into a single job with multiple steps. That way when one step fails, the entire build will fail, no unnecessary Hudson cycles will be spent, and you will not receive redundant emails. To add steps to a build, click "Add build step" and select "Invoke Ant" (or whatever other action you want it to take).
You can use the build trigger "build after other projects are build" to put projects up- or downstream from one another. Then you typically let the lighter builds go first (like simple compile).
I am trying to create 1 package with multiple build configurations. The first will checkout the code, build it (Solution File configuration), and run nunit tests. If that succeeds, another will then build in release mode. If that succeeds, a final script witll package up the output, and mark it as an artifact.
The problem I'm having is that I don't know how to tell TeamCity not to create new directories for each step, and as a result, the steps are failing. Is there a setting for this? It seems like the dependencies tab would be an appropriate place to look, but I don't seem to understand the instructions, and my tinkering so far has been fruitless.
I basically skipped most of the TeamCity workflow, and instead used a scripting language to handle all of this. (I used Rake and Albacore, which I highly recommend for .net projects)
I'd caution you not to use powershell w/ TeamCity. You have to wrap everything in .bat file, which is fairly excruciating.
So the result, is that I have 1 checkout, and everything builds from this point. It's drastically cut down the amount of time required for the builds, though perhaps that wouldn't be the case if I had a lot of agents available.