We have 2 project configurations A and B. B depends on A. A commiter makes a change in project A that causes build failure in downstream project B.
Is there a way in TeamCity to notify the commiter of project A that the B has failed because of his change?
Jenkins/Hudson supports that using upstream-individuals:A as an email address in this particular situation.
I tried to set it up through snapshot dependencies as Danere pointed out and it is working. Since the TC way is different from what you probably tried with Jenkins here is my setup:
I added another project to the chain named C that contains 2 VCS: projectA and projectB and a dummy build step.
Project C is configured to be triggered by any VCS change
Project C has a snapshot dependency on project B
Project B has a snapshot dependency on project A
Both project A and B do not have any triggers.
The project C could be probably eliminated but my configuration is more complex and the last step performs system tests and I didn't want it to monitor all VCSs of all the upstream projects.
Related
I want to create a one-click release build. I am fine creating multiple build configurations and linking them together or building everything in one build configuration.
Module Dependencies are mentioned below:
Module C depends upon module A and B. Module D depends upon module C.
A > C > D
B > C
There could be instances where nothing has been changed on module A or B. If nothing has been changed in a module, I do not want to build and release them as it was already released in past. This would have been simple if I need to build all the modules every time which is not the case.
Let us consider a scenario that there is a change in module B. In this case, I only want to build module B, C & D (but not A).
Is there a way this could be achieved with build step or parameters or by any other means in Team City?
In the Snapshot Dependencies enable the checkbox
Do not run new build if there is a suitable one
Only use successful builds from suitable ones
I recommend using Artifact Dependencies with Snapshot Dependencies.
Enable the follows settings
Build from the same chain
Do not run new build if there is a suitable one
Only use successful builds from suitable ones
Then the TC will not build some of build chain if no chainges
I have to make build architecture of my small project and I wonder how to proceed?
I have classes in one project for the so call core-part which can be used in other projects and api part in the first project which uses core-part.
So how to act?
To make multi-module Maven build and to produce 2 artifacts (which to upload to our company repo) and api-part have project dependency to core-part:
pom.xml
|
/core-part
|
/api-part(depends on core-part)
Create separate projects
Project1
/core-part
|
pom.xml
Project2
/api-part
|
pom.xml -> depends on project1's GAV artifact
Project3 ,...n depends on project1?
"Strong advice" : a project belongs in a multi-module build if release of that build requires release of that module, and vice versa. Multi-module projects should consist of things that must be released together.
An API should [practically] never depend on the release of its implementation, whereas the release of an API [nearly always] dictates the release of a new dependent implementation.
If you're not doing formal releases (why aren't you doing formal releases?) then this advice is still in force but less strong.
1. is the way if you'd like to build core-part and api-part within one build by building the aggregator/multi-module project (which has to have <packaging>pom).
There is actually a third artifact created (and installed and deployed to the repositories) then: The one for the aggregator project.
2. is the way if you'd like to handle (build, install, deploy) core-part and api-part individually. (An option you still have with 1. anyway.)
See:
POM Reference, Aggregation (or Multi-Module)
Maven: The Complete Reference, 3.6.2. Multi-module vs. Inheritance.
I have a situation like where i have two projects.
For one project i am successfully able to run analysis. 2nd project is new and it is completely using code and same structure and same modules of project 1 and we can say it is extension of Project 1. While i am running code analysis it is saying modules are already part of project 1
[ERROR] Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.7.1:sonar
(default-cli) on project citi-sgp-au:
Module "com.xxxx.xxxx:xxxxxx" is already part of project "xxxx-xxx-xxx222"
-> [Help 1]
Any guidance on this?
SonarQube cannot analyze 2 different projects with the same id (e.g. groupId and artifactId).
You can change id of one of the two projects or use sonar.branch property.
From SonarQube Wiki:
sonar.branch - Manage SCM branches. Two branches of the same project are
considered to be different projects in SonarQube. As a consequence
issues found in a project A in a branch B1 are not linked to issues
found for this project A in a branch B2. Currently, there is no way to
resolve automatically issues of B2 when they are resolved in B1 as
again A-B1 & A-B2 are considered as separated project.
Because you are using the same code and same structure, I assume that the module of both projects end up having the same key. In SonarQube, it is not possible to have a module that belongs to several projects.
So the solution is to make sure that the modules of your 2nd project have unique keys.
Note: if you're using Maven, this is very simple: just make sure that your second project has a different groupId.
I have a build chain with two projects: A is the root project, B depends on it. B has two dependencies configured: an artifact and a snapshot dependency. One build configuration for B has an environment variable (parameter) set. However, I also need this parameter set for the root project A.
Is there any way in TeamCity 9 to pass a build configuration parameter from a project to its dependency (in the same build chain)?
Since TeamCity 9.0 it is possible to override the dependencies parameters by redefining them in the dependent build:
reverse.dep.<btID>.<property name>
For TeamCity 8 and below unfortunately the only way parameters can be passed on is in the direction of the build chain - the reverse of what you want - these properties are called Dependencies Properties:
Dependencies Properties
These are properties provided by the builds the current build depends
on (via a snapshot or an artifact dependency).
Dependencies properties have the following format:
dep.<btID>.<property name>
Dependencies properties flow from the root of the tree to its leaves (in the direction of the build chain flow) , but not the other way round, so the properties of A can be accessed in B.
This is clarified in the docs here:
Parameters in dependent builds
TeamCity provides the ability to use properties provided by the builds
the current build depends on (via a snapshot or artifact dependency).
When build A depends on build B, you can pass properties from build B
to build A, i.e. properties can be passed only in the direction of the
build chain flow and not vice versa. For the details on how to use
parameters of the previous build in chain, refer to the Dependencies
Properties page.
I've had a similar use case for the reverse flow before as well - the workaround was not pretty - basically instead of triggering the build chain directly we would trigger an independent build (let's call it X) that was only there to hold the build parameters - then modify the build chain to have the root build (A in your case) depend on the last successful build of X and have the build chain trigger on a successful build of X - this should accomplish what you want.
For TeamCity 9 see #Alina's answer (which should be the accepted answer).
I'm using sonatype nexus repo hosting and I have two artifacts where A depends on B but they are separate projects (not multimodule). I staged B as 1.0.0 but now I want to stage A with a dependency on B-1.0.0 and not on its snapshot; however, because B is still just staged and not released, maven complains that it can't find B-1.0.0. What is the correct way to do this? It doesn't make sense to me to have to release the dependency (B) without it being tested as part of another project (A)
What am I doing wrong? IIUC, staging repos are dynamically created, so adding the (temporary) staging repo as a <repository> in project A doesn't sound good either
as a secondary question, I also would like to know if I am supposed to stage the main artifact (A) in the same staging repo as B or if I should close B and stage A in a new staging repo
You should have a separate repository group from public and have it configured as the target group for your staging profile for project A.
Then when you build project B you use that group and it will be available for building that project.