We are using TeamCity 9 and we have defined build configuration looks like:
--> unit tests ---------|
^ ˇ
compile ->+-> integration tests ->+--> deploy
ˇ ^
--> acceptance tests ---|
Dependencies between build are defined as Snapshot dependency (documentation). All tests builds are running in parallel, but I need to define order because integration test needs more time than others so it'll be good to run this test build first.
It's possible to define order or priorities for each build in chain?
Order of builds (waiting mechanism) can be managed by using the build feature named shared resources.
See page # Jetbrains :::
https://confluence.jetbrains.com/display/TCD9/Shared+Resources
Related
I have a multi project (> 20) git repository. When I execute a gradle build, I only want the test tasks in the projects where java classes (inputs) have changed since the last time I built to execute. I tried specifying .../build/classes/main as inputs and .../build/classes/test as output for the test task thinking gradle would detect that these did not change between builds and not execute the test task, but no luck.
I think that should be the default behavior of Gradle. Have you tried the --info or --debug flags to try and see why Gradle thinks it needs to execute the tests?
Unless the issue is the multi-project build itself. If you have A & B, and B depends on A, and you change A, then the tests of B are run even though B did not change. However, since a dependency of B changed, it would likely be correct for its tests to execute.
Good luck.
Consider a Gradle plugin that adds three tasks to a project - a buildZip task to create a distributable zip of the project, a publishZip task to publish that zip to a shared repository, and a cleanZip task to clean up any local version of the zip. For local development, cleanZip buildZip will be used frequently, but the automated build system will be running buildZip publishZip cleanZip.
One of the projects in which this plugin is being used wants to run their build using Gradle's parallel flag to allow the different parts of the project to be built in parallel. Unfortunately, this runs into a problem with the zip tasks - buildZip depends on the project actually building, but cleanZip doesn't have any dependencies so it can run right away, leading to the automated build system not being able to clean up.
Declaring any dependencies between these tasks isn't a good idea because they should be able to be run separately. Also, I can't specify mustRunAfter (at least between buildZip and cleanZip) because sometimes clean should be first and sometimes build should be first.
How can I tell Gradle what order to run these tasks in, in a way that will be honored by --parallel and isn't hardcoded to have a particular one always run before the other?
What you can do is: detect if gradle is run with --parallel and based on this configure dependencies between tasks appropriately. It can be done in the following way:
println project.gradle.startParameter.parallelProjectExecutionEnabled
I have a TeamCity project which includes 4 configurations and the build chain needs to look something like this:
Build which can be triggered manually and executes .bat scripts that compiles a bunch of artifacts for the Deploy and TEST to pick up.
Deploy and TEST – Region 1 has an artifact dependency on the Build config.
Deploy and TEST – Region 2 has an artifact dependency on the Build config.
Since I wanted both Region1 and Region2 to run in parallel as soon as Build is successful, I added a Snapshot dependency to Deploy and TEST – Region 1 and Deploy and TEST – Region 2 on Build config
Now I need to configure the Test Status config just to report the failure/success of the previous config (Deploy and TEST configs).
How can this be achieved? Also, do I need to tweak my set up anywhere for the use case I am trying to achieve?
The setup looks correct. To get the build chain status in Test Status configuration, you need to add snapshot dependencies on Deploy and TEST – Region 1 and Deploy and TEST – Region 2 configurations. If any build from the chain fails, Test Status build will also fail with status: "Snapshot dependencies failed: ... < build configurations names >"
If you add these snapshot dependencies and run Test Status via UI, the whole build chain will be added to the queue. Also you can configure one VCS trigger in Test Status build configuration with option "Trigger on changes in snapshot dependencies". With this options enabled, the whole build chain will be triggered even if changes are detected in dependencies, not in the resulting build.
This article can be helpful.
We have a TeamCity build configuration which does a deploy and then runs integration tests.
Deploy system
Run test suite A
Run test suite B
Run test suite C
If test suite A fails, B and C should still be run (likewise C should run if B fails). To satisfy this, the build steps are set to run "Even if some of the previous steps failed". However, I don't want any of the tests to run if the first step to deploy the system fails.
Is there a way of terminating the build if the deployment fails, but to keep running all tests of there are individual tests which fail?
You could chain the builds together so have a build for 'Deploy the system' and then have a separate build for 'Run the tests' which has your 3 steps A,B and C in it. The second build takes a snapshot dependency on the first build which means that it will kick off when the 'Deploy' build has completed, but it won't kick off if the build fails.
The steps in the second build could then be set to run even if the previous steps fail as you have it now and they would all run.
Are there any form to run unit test with surefire in parallel but by module? For example, we are using build in parallel by defining number of threads. Can we apply this techniques by defining number of threads to execute test in parallel by module. For example, firstly, the project is compiled. Secondly, we can use compiled project for run our tests by following form: mvn -T 4 test?
There is a different between running the build parallelized and the tests parallelized. The first one is done by using the -T option but the test can be configured in maven-surefire-plugin.