we have some depending builds, and i want to start them all after all... (talking of RTC/Jazz build definition, which are used in RTC/Jazz source control - we use the build-engine from RTC/Jazz)
build framework
build server [depends on 1.]
build (start) unit test server [depends on 2.]
build client [depends on 1.]
build (start) unit test client [depends on 4.]
build (generate) allover report [depends on 1.-5.]
build (publish) if all was ok... [depends on 6. if ok]
is there a way to add a sequence into different build definitions? the builds are performed on two different build engines which are even on different build server. right now i have to copy the results and publish all manually...
one important note: these are the nightly builds, where all work of the day is brought together... they are triggered via the 'schedule option' in each build definition. but think what happens when one build is not yet ready and the other already starts? (this already has happened and i want to avoid it furthermore)...
what is the proper way to handle this? (maybe i was using the search option wrong but no results in google and Stackoverflow)
The build scheduler management in RTC isn't as complete as a TeamCity or Jenkins (actually, RTC4+ allows to delegate that job scheduling feature to Jenkins)
But if you want to introduce a sequence between builds definitions, you can look at post-build delivery, introduced in "How to keep your streams flowing smoothly in Rational Team Concert 3.0.1".
The idea is, if a build succeeds, to trigger a deliver to another stream (post-build deliver step).
If that other stream is monitored by another job, that job would only starts if the previous one succeeds: sequence achieved.
This seems simpler than adding pre/post-build extensions points.
Note that post-build steps currently don't get run when a build is invoked by the Team Concert Plugin for Jenkins. See WI 277270.
You can place a post request to jour jazz server after each successful build like:
localhost:/jazz/service/com.ibm.team.build.internal.common.ITeamBuildRequestService
<request>
<method>requestBuild2</method>
<interface>com.ibm.team.build.internal.common.ITeamBuildRequestService</interface>
<parameters xsi:type="com.ibm.team.repository.common.services:ComplexDataArg">
<type>COMPLEX</type>
<value xsi:type="build:BuildRequestParams">
<allowDuplicateRequests>true</allowDuplicateRequests>
<personalBuild>false</personalBuild>
<buildDefinition itemId="YOUR_BUILD_DEFINITION_NAME" />
</value>
</parameters>
</request>
Related
We're currently building an internal apparatus to run unit tests on a large C++ codebase, using Catch2 for the framework and our in-house VS test adapter (using [ITestDiscoverer] and ITestExecutor) to attune them to our code practices. However, we've encountered issues with unit tests not always being discovered after a build.
There's a couple of things we're doing out of the norm that may be contributing. While we're using VS2019 for coding, we use FASTBuild and Sharpmake to build our solutions (which can contain countless projects). When we realised that VS would try to build the tests again using MSBuild before running them (even after a full rebuild), we disabled that behaviour in the VS options. Everything else seems to be running as expected, except that sometimes tests aren't picked up.
After doing some digging (namely outputting a verification message to VS's Tests Output the moment our TestDiscoverer is entered), it seems like a test discovery pass isn't always being invoked when we would expect it, sometimes even with a full solution rebuild. Beyond the usual expectation that building a project with new changes (or rebuilding outright) would cause a pass to start, the methodology VS uses to determine when to invoke all installed test adapters seems to be fairly blackbox in terms of what exact parameters/conditions trigger it.
An alternative seems to be to allow the user to manually execute a TD pass via some means that could be wrapped in a VSPackage. However, initial looks through the VSSDK API for anything that'd do the job has come up short.
Using the VSSDK, are there any means to invoke a Test Discovery pass independently from VS's normal means of detecting whether a pass is required?
You would want to use the ITestContainerDiscoverer.TestContainersUpdated event. The platform should then call into your Container Discoverer to get the latest set of containers (ITestContainerDiscoverer.TestContainers). As long as the containers returned from the discoverer are different(based on ITestContainer.CompareTo()) the platform should trigger a discovery for the changed containers. This blog has been quite helpful in the past: https://matthewmanela.com/blog/anatomy-of-the-chutzpah-test-adapter-for-vs-2012-rc/
Within our company we use TeamCity for both automatically triggered build configurations, that are triggered quite regularly, and also manual not-as-often build configurations.
Examples of automatic builds are: up-to-date light builds, tests, etc. These are usually triggered because new code/data is available.
Currently, there is big chained process for a release of our product on all platforms. This is done manually by running the last composing build config, and it will do all the build configurations it needs to. None of them are ever automatically triggered, and all are unique to the release build chain.
My questions are, as the amount of agents we have available is quite limited, is it possible that the release process has priority in a way that it would:
Pop any automatic builds and add them again to the queue (just cancelling would be fine, but less desirable) as long as the release chain is ongoing?
Delay any automatic trigger build until the release build chain is finished?
I would understand that there is no existing solution for this, as the only thing I'm using for now is the priority classes. And even though it does work nicely for deciding what stuff on the queue to execute first, it doesn't affect any ongoing build process.
Do you know a great solution for that, or have an idea on how I could tackle this myself by implementing something using, for example, the REST API?
TeamCity have custom build queue priorities feature. You can configure your release process build configurations to have higher priority, so they will run before any non-prioritized build, and there no need to remove/readd builds from/into queue.
I have one requirement of one build definition should invoke the other build definition.
Based on the result of the first one, the second one should get triggered.
Is there any option?
Following the article "
How to keep your streams flowing smoothly in Rational Team Concert 3.0.1", you could set up the post-build deliver step in order to deliver to another stream, monitor by another build.
If the first build goes well, it delivers to the second stream, which is monitored by a build workspace associated to a second build, which will start then.
Note that only a RTC 4.0.6+ (February 2014) allows to fine-tuned the conditions for which a post-build deliver will be triggered.
The auto build completes (when 'Disable Tests' is set to true in build definition) but when I enable tests the build doesn't complete.
I'm building as Debug/AnyCpu. I've copy-and-pasted the MSTest line and ran it in a shell on the build server and I got some assertion fails. Thus, I think the server's waiting for a response to ignore/retry these assertions, does anyone know how I can fix this?
If you want to using assertions during your unit testing, I would recommend using the Unit Test Framework Assert class instead of Debug.Assert.
See this method for more details:
http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.assert.fail.aspx
You have different ways to assert (AreEqual, AreNotEqual, IsTrue, etc.).
Hope this helps.
Unit test using a release build on your server - it won't have any asserts in it.
What do you mean build doesn't complete? The build log will tell you what is the most recent action. You might want to set the logging level to detailed for the build to see more information. Also one issue might be that you have configured the build to fail if tests fail. In that case you could add Ignore attribute into those tests:
[TestMethod]
[Ignore]
public void TestMethodThatFails()
Of course you should fix those tests rather than ignore them but that is not the subject of this question.
I'm trying to setup a post-build event in .NET 3.5 that will run a suite of unit tests w/ MS test. I found this post that shows how to call a bat file using MbUnit but I'm wanting to see if anyone has done this type of thing w/ MS Test?
If so, I would be interested in a sample of what the bat file would look like
We were using NUnit in the same style and decided to move to MSTest. When doing so, we just added the following to our Post-Build event of the applicable MSTest project:
CD $(TargetDir)
"$(DevEnvDir)MSTEST.exe" /testcontainer:$(TargetFileName)
The full set of MSTest command line options can be found at the applicable MSDN site.
Personally I would not recomment running unit tests as a part of the compilation process. Instead, consider something like ReSharper (+ appropriate Unit Test Runner or how do they call these nowadays) or some other GUI runner.
Instead of a doing it in a post build event, that will happen every time you compile, I would look at setting up a Continuous Integration Server like CruiseControl.Net. It'll provide you a tight feedback cycle, but not block your work with running tests every time you build your application.
If you are wanting to run the set of tests you are currently developing, Anton's suggestion of using ReSharper will work great. You can create a subset of tests to execute when you wish and it's smart enough to compile for you if it needs to. While you're there picking up the demo, if you don't already have a license, pick up Team City. It is another CI server that has some promise.
If you are wanting to use this method to control the build quality, you'll probably find that as the number of tests grow, you no longer want to wait for 1000 tests to run each time you press F5 to test a change.