We have a build that among other things, runs MSTest. We have separated some tests into "Nightly" and everything else, to keep our build running quickly.
We want:
On SCM change trigger, run all uncategorized tests
On nightly schedule, run all tests including "Nightly" category
I was setting this up with parameterized builds, but there isn't an option to select parameters on SCM change or on a schedule.
Is there a workaround to make this work? Maybe using a second build project?
Got it to work with 2 projects:
My original project is setup with SCM trigger, running the "Fast" category only
Setup a second project with a scheduled nightly trigger, its only build step is to trigger the first project running both "Fast" and "Slow categories.
Related
TLDR: How can I arrange it so that a snapshot dependency does not trigger new builds?
For my test processes to run, they need to run on a "Test" environment. Creating such an environment is simple, but lengthy; it can take as much as 45 minutes to an hour to finish building a test environment. Further, the name of the environment, and other such variables, is not fixed until the environment has finished building.
In my TeamCity build definition, I could put "build environment if missing" as a build step. However, that means that the first test of the day will take 45 minutes to run.
Instead, we created a separate build, that is scheduled to run every morning, that builds the test environment for the day. Our test build then has a snapshot dependency to that build in order to use the parameters of that build to determine the environment information, and everything works as expected, except for one issue:
When a new test is run, it frequently seems to trigger a rebuild of the test environment creation.
We don't want this to ever happen; the test environment creation is 'done' for the day and should not need to run again until tomorrow. How can we achieve this?
You already have time based trigger => environment will be prepared every morning
Create Snapshot Dependency in your product TC configuration (not in that one which is preparing test environment) and tick 'Do not run new build if there is a suitable one'
Your configuration used to setup test environment should not have any VCS root (or point to some calm place of source control where submits will not happen). To physical setup your environment you should not need any source code mapping etc. - you may consume everything needed through your own NuGet packages for example.
Note: In this workflow every build of your real project will enlist build of configuration which sets test environment (so it's physically in build queue) but
when it's turn come up it will compare changes since last build => no submits on VCS found (it's pointing to calm place in SourceControl due step 3)) and so build will be skipped in <1s
I'm wondering if there is a way to force TeamCity to run a given build step even if preceding build steps fail. I want to do this to clean up after the build and terminate any started processes etc.
In Msbuild you can set the property ContinueOnError for many tasks. I usually add this using a property so it can be switched on and off:
<MSBuild Projects="my.csproj" ContinueOnError="$(ContinueOnError)"/>
Then you can set it on and off via teamcity.
So if you do this for a build step it should continue thru to the others.
I don't know if you can do it with build steps, but I've done it with two builds. The second one uses a finished build trigger pointing at the first. Finished build triggers can be configured to fire even if the first build failed.
We do our builds by constructing NAnt scripts, and then using TeamCity's NAnt runner. NAnt (well, actually NAntContrib, but still ...) has a try ... catch ... finally mechanism that does what any programmer would expect - run the catch code if the try code fails, and run the finally code no matter what happens. We use it for the same purposes as you want, plus to collect artifacts that we want the build to publish even in case of failure (like test logs).
Newer versions of TeamCity has this feature built in.
I'm running a maven build in Jenkins and my builds are failing because Jenkins isn't smart enough to clean up after my build - it just tries to delete the entire workspace and the builds fails immediatly. Is there a way to NOT have jenkins fail because of this (or even try to do it), but instead let my "mvn clean" script run first? If I can do this then I can do the specialized cleanup that is required.
I suspect that you are using Workspace Cleanup Plugin. First thing to do is to check what happens if you do it as a pre-build step, not post-build.
Alternatively there is a custom step in the build that tries to wipe out the workspace. See what happens if you invoke it as the first build step, not the last. Or try using the aforementioned plugin.
If it does not help, here are other general clenup strategies you may employ:
Start another job as a post-build step that will cleanup for the upstream job.
Have a regularly scheduled (say, nightly) job that will do the cleanup. In this case you'll probably need to 'partition' your workspace by builds - i.e. create a separate subdirectory in the workspace for every build instance (keyed by BUILD_ID) so that builds do not accidentally use leftover files from previous builds.
Have a cleanup build step in your job. In this case you do not need to create extra jobs. However, as it runs before the build is over it may not be able to cleanup completely (say, it won't be able to delete the artifacts that need to be archived in a post-build step).
To summarize: Yes, you can run you script first, just make sure it does not delete things prematurely. Also examine your job configuration for where that cleanup of yours is called and set it up as a pre-build step or remove it.
I am using MSBuild for CI. I was looking recently to psake as an additional tool for creating scripts for daily builds as I need to do some updates to our builds which will be easier in psake. For the moment I’m not looking to replace our existing scripts as it requires a lot of work but keep the existing ones and add new using psake.
My question is - when I create a build in TFS how can I run the psake scripts after the solution is built? My understanding is that I need to add a new target after the build is executed and execute the psake/powershell. Is this the right way to do it?
Yes that is how you would do it. It is best to separate different parts of your build script so that if you want to change something, you can proceed with ease.
So, Ideally, you should have a task for compiling your solution, another for running the tests, another for packaging the source and so on ... I recently started using psake, and this is a good reference in case you want to look up something.
The right way to do this is to use TeamCity to run your psake build scripts. In your psake scripts you would create a psake Task that calls msbuild via exec { msbuild yourSolution.sln }.
When we build a Maven project without doing mvn clean, we sometimes get "voodoo errors" such as NoSuchMethodError. I believe these are caused by moving/renaming files.
I don't want to use the clean option in the CI, because it makes the build process take much longer. Is there another alternative?
You should always use clean in a CI build. CI builds must be reproducible and that requires starting from scratch!
And about the process taking longer: the whole point of using CI (one of the many) is that you can keep working while it's running, so that should not be a problem.
But what I like to do is use multiple layers of CI per project:
A first job compiles and executes some basic tests*, this build should take less than 5 minutes
if that succeeds, a second job executes all tests*, code metrics, javadocs etc
if that succeeds a third job deploys the build to a test server
(Or you can let the first job trigger both the second and the third job at once)
* You can implement the some tests / all tests functionality by configuring the maven surefire plugin differently per profile)
We have three build targets:
Continuous Integration: Builds without doing a Clean, and only run the tests identified by Clover. This runs after each commit. On success it deploys to the test server.
Nightly: Does a clean build and runs every single test. This runs every night. On success it deploys to the test server.
Release: Same as Nightly plus creates a source control label. Run manually.
The nightly build is more trustworthy in that a clean build is conducted. However, the CI build is quicker meaning feedback is faster on those occasions.
There is an underlying problem here with the build time, but this is at least a work around while you look at more permanent ways to address that.