Our MSBuild definitions build both Debug and Release build configurations. (This is due to the deployment system we use and can't be changed.) The problem is that since we run automated tests, they are run twice, once on each build. Is there any way for me to configure tests to be run only on release build?
We're using VS2010/TFS2010.
In the TFS build definition, under the Process tab, under Automated Tests -> Test Sources -> Test Sources Spec, can you modify the path spec to include the name of the releases folder so that the test binaries from the releases folder only are tested?
Change the spec from:
**\MyApp*Tests.dll
To read:
**\Release\**\MyApp*Tests.dll
It looks like a little tweak to Nick's answer did the trick.
..\Release\**\MyApp*Tests.dll
Related
I have a build configuration that does my building and unit testing for all of my branches of my project. I have another configuration that does my deploying. I need the first configuration to do the build with a "Debug" target if its against a "development" environment and a "Release" target against the rest. Is there a way to go about this without having to make different build configurations?
For all the builds I manage here at my job, we always create different build configurations in TeamCity for Debug and Release. I don't know more about your build environment so obviously I can't answer specifically.
You can however reduce almost all the duplication by using templates. Which is nice. Then the only unique information in your debug build is the word 'Debug', and same for your 'Release' build.
We have started using Appveyor for CI with our Github repo and all has went fine. We have our build script working (appveyor.yml) in the repo, and it successfully builds and produces an artifact. Now on to my question
We are trying to pair our builds now with codecov.io which says it will scan it during the CI build. And it does support appveyor, it merely says to add this to the yml
after_test:
- bash <(curl -s https://codecov.io/bash)
Which we did, but nothing happens. Does this mean i need an actual test script to run, before it will send off the code to codecov? It is a C# project, and we have it compile, and generate the .exe which we then package into a zip which can be downloaded.
What are the point of these "test scripts" when we already know it compiles and produces an exe? I am a bit confused on how to use this properly..
I believe here https://github.com/codecov/example-csharp is good example of running codecov tests on C# project with working Appveyor configuration. Please look at readme.md file in that repo for greater detail.
From the Documentation
You need to add the OpenCover nuget package to your Visual Studio solution which is used to generate code coverage analysis:
PM> Install-Package OpenCover
Secondly, you need to either write a PowerShell script (if you intend to generate code coverage and upload the result interactively) or you need to add a few entries in you CI config file (if you intend to let your CI generate the coverage).
When I run
./gradlew clean assembleRelease
my binaries are built, but the unit tests do not run.
When I run
./gradlew clean build
all binaries are built and all unit tests are run, twice... once for debug and once for release.
How can I achieve what 'clean build' does but only for the release buildType?
Context: The main problem I am trying to solve is what is the proper way to configure a jenkins job to build assemble and run all unit tests for the RELEASE buildType only.
The way I have solved this for now is by adding this code block to the bottom of build.gradle in each module of my project:
project.tasks.assembleRelease.dependsOn {
project.tasks.findAll { task ->
task.name.startsWith('testRelease')
}
}
This does what I need it to do, such that when our jenkins server job runs:
clean assembleRelease
All the release unit tests are run and the artifacts are all created.
Not sure if this is the best/cleanest solution.
This worked for me:
gradlew clean check assembleRelease
This cleans and verifies (includes running tests) for all subprojects (even plain java ones) and then assembles only the release buildType, i.e. dexing and signing is only done as specified in the release closure.
I'm not sure if that's the cleanest solution, either. Still, it does not append boilerplate to build.gradle files and its is faster than running the clean build tasks.
A good overview over gradle's anchor tasks assemble, check and build is provided by the Gradle Plugin User Guide.
Our project uses CMake to configure our code. We use Ninja along with a distributed build system. A number of people on our team use Eclipse CDT. We run CMake with the "Eclipse CDT4 - Ninja" generator and the result is generally pretty good.
The issues is that any time a CMake file is changed and you ask Eclipse to build the code it regenerate the eclipse project file overwriting any manual changes you've made to the project.
For example the default build command that it provides the eclipse project is /usr/bin/ninja when in fact I want to take advantage of our distributed build system and set the build command to /usr/bin/ninja -j16. It would be nice if I could have the project file that CMake generates automatically include this setting change.
The other setting I am most interested in preserving is the C/C++ Project Paths->Source. As a general rule we place our CMake build directory as a sibling to the main project directory i.e. ./project ./build. We want to include some files in the build directory in the Eclipse index to make code completion and other tools work better. The default project doesn't include the build directory in source path and thus it does not get indexed.
Is there some way to remedy these issues?
I found a solution to build command issue.
When you run cmake to generate the eclipse project include the additional argument:-DCMAKE_ECLIPSE_NINJA_ARGUMENTS=-j100. I haven't confirmed but I believe a similar command is required for eclipse make projects -DCMAKE_ECLIPSE_MAKE_ARGUMENTS=-j100.
Unfortunately this feature is poorly documented and I have not found a solution to my other issue.
I have a C++ Builder 2010 project that's being built using TeamCity. I noticed some strange errors and after reading up on them I understand that I have to set a few variables located in rsvars.bat. I would like the build script to execute the bat file to set up the environment before performing the actual build. How do I best accomplish this?
Can I just use a <exec /> command at the very beginning of the file or is there a better way?
One way would be to run wrap the build in a script that calls rsvars.bat AND build commands. That would make the variables survive during the execution of the build.
But since I use TeamCity I like it to be a real msbuild step and not msbuild wrapped in something else. I was thinking of having the buildscript setting the variables from rsvars.bat into Machine or User at the start of the build and then remove them at the end, not nice though.
I finally just went with just adding the configurations to the Build Agents environment configuration in TeamCity and keeping installation paths identical between agents.
You can create a new build step and then specify a custom build step order so a new build step will be the first one.
See Configuring Build Steps
Add them as Build Parameters -> Environment Variables (in the build configuration), straight forward and generally works. The build parameter/environment variables will be setup automatically as environment variables on the build agent running the job.
You can then make a template of the build and reuse it.
Assumes that the 'paths' are the same on all build agents, which is generally the case. If not your suggestion of doing it by build agent is the way to go.