So i have 4 project depend on each other with 4 different configuration in team city. when i run 1 they all run. but , each one of them is doing check out when starting his run , so it is possible that some files were committed during build and than it is not the same revision.
i want to be able to checkout them all at the beginning so the build will be always the same revision.
does anyone has an idea?
If they are all pulling from the same repository you can create a snapshot dependancy from the dependent build to the build they are dependent on. What this means is that they will use the same sources as the build that they are depending on.
Snapshot Dependency
You could group the projects logically in version control and add a parent script to build them in order. You then have one TC checkout/build that does all 4.
We use maven multi-module builds in Hudson for the same purpose.
Related
I have a jenkins job to create multiple debian packages. Each created package file is archived as artifact of the build. This works well so far.
Currently I am trying to to trigger multiple builds of another job, one for each created package file. This job should install each package in an isolated vagrant box and do some tests on it.
The question is how to trigger the builds. As it would be nice to parallelize the builds it is not easy as doing one build for all packages. The number of packages is not always the same, so it is very uncomfortable to duplicate the job for each package.
Thanks,
krissi
To act on every build of a project, you probably want "Promotions". Read about it here:
How to promote a specific build number from another job in Jenkins?
We are using TFS2010 for source control and TeamCity 8.x for CI. In our project we have Main branch for releases and bug-fixes and Dev for most of the development. Build steps for both branches are identical. and we have a few build configurations to go through:
I can't seem to make TeamCity to do checkout on a single branch and run build only on the branch that was checked-in to.
First attempt: I've added a VCS Root to point to $/Root that contains both Main and Dev branches and created checkout rules:
First checkin to Main works fine. Checkin to Dev after fails like this:
where DoNotExportAttribute is the file that was modified in the Dev branch. Even if I have
checkbox against "Clean all files in the checkout directory before the build".
My second attempt was to add both of the branches as VCS roots:
But this caused checkout of both branches into the same directory and whatever was checkout first was overwritten by second branch.
Is there a remedy for our case without creating separate configurations for every branch? (we started from config-per-branch, but that proven to be maintenance heavy for the number of steps we do in build)
If I understand correctly, you're trying to use a single TeamCity project for both your main and your branch builds. I would not recommend doing that. By re-using the same project for both your main and your branch builds, you will be sharing version numbers between two different beasts. Version 1.1.4 of the build might be a main build while version 1.1.5 might be a branch build.
By looking at the artifacts created by the build, it will also be difficult to identify which source code was the one selected and included into that artifact. Is the executable a main or a branch executable?
The way we solved the main vs branch problem was by creating a "template" project which contains all our build configurations (each one set up as a Build Configuration Template so they can all be changed in a single location) for building our software. Both the main line and the branch projects are created by copying this "template" project and setting the VCS root to the appropriate directory location.
We run five build agents and each build takes a fair amount of time. Having individual projects for each branch allows us to run builds in parallel if the main and any of the branches happen to have been modified at the same time whereas with one single project, the builds would be done serially.
Hope this helps.
My current setup consists of:
Project job - it's the one, that fetches the sources, deploys to the test environment and runs tests across the test env
Building job - it's a job that runs on a special machine which builds the sources into deb packages.
The issue: it's fairly easy to retrieve the deb packages from building job back (as a job artifact), but how would I pass the sources from project job to a building one?
They run on a different jenkins slaves.
What are the possible options?
Note: the building job isn't a specific job for this particular project. Several projects use it as a helper to build deb from the sources, so I cannot hardcode anything project-specific there.
You want to look into the CloneWorkspace SCM Plugin
If you are using SVN, you might want to look at the Tracking SVN Plugin. This allows you to pull the same version out of SVN as another job. We use this so that we can create both a "debug" and "release" build from the same SVN revision. The debug version builds first. If it succeeds, the release version is built using the same revision that was built for the debug.
We are using TFS2008 and TeamBuid to build our product. I have SolutionAA in TeamProjectAA that uses a file reference to a compiled library (SolutionBB) that is checked in to TeamProjectAA. Now this works fine. Now the source code to the library is checked in TeamProjectBB. The problem arises when I need to due a full build using TeamBuild. I have a build project for SolutionAA but I need to compile SolutionBB and version is correctly so it can be distributed with our install.
Is there a way to chain two TeamBuilds together? Or can I build a solution from another TFS project from another TFS project?
See this post (http://bit.ly/tfschaining) which contains an example Custom Task which can queue a build.
Your full build can start by running build AA and then queue build BB.
I would suggest, though, that you get a better versioning scheme for your dependencies. You are running AA as if it is an independent project and should treat it's output as such in BB. Consider pulling manually from AA as you it suites your status on BB. That way BB can have intermediate builds and BB can only pull when its ready to take on the changes in AA.
I'd suggest checking in the compiled library as part of the TFS Build for SolutionBB. Then, include the location of that compiled library in your workspace mapping for the TFS Build of SolutionAA and configure it with a continuous integration trigger. The build of SolutionAA will get triggered whenever the compiled library for SolutionBB is modified in version control.
If you follow some of MS's recommended branching strategies you can easily end up with a project structure such as:
$PROJECT\
DEV\
MyProject
STAGE\
MyProject
PROD\
MyProject
Now let's say I have three different build definitions. One each for DEV, STAGE, and PROD. This should be common considering that the build definition will define the exact solutions to build.
If I turn on CI for each of them, STAGE will be built even though the checkin occurred in DEV...
Now my question. How can I limit the build definition to execute only when a check in occurs in either a path or a solution that is part of the build definition?
When defining the working folder configuration screen - only have it start at the root of the branch you want to build.
For example, your DEV branch would be configured so that $/TEAMPROJECT/DEV/MyProject was mapped to $(SourceDir) rather than the default mapping which would have been set to just $/TEAMROJECT.
FYI - Personally, I only have CI Builds on Dev branches and queue manual builds for a push to QA. I also normally don't do a re-build for production but just push the build binaries that were QA'd. I also keep by build configuration folder inside the branch i.e. $/TEAMPROJECT/DEV/TeamBuild rather than the default $/TEAMPROJECT/TeamBuildTypes and therefore changes to the build configuration are also pushed up through the branches. That said, you have to stick with the default if you wanted the build configuration to be visible to VS2005 clients.
Hope that helps,
Martin.