We are using Teamcity in conjunction with the SonarQube plugin for some maven multi-module projects.
As we are potentially adding modules to one or the other project, I would like to set the "Modules" parameter of the SonarQube plugin programmatically or via some environment variable instead of having to manually edit it in the plugin's config.
Is there a way to do this?
For my TeamCity setup I have a global variable for my SonarQube exclusions. I can change all exclusions or override for specific projects. If you want to set this programatically, you could use the TeamCity API to update a similar variable either on the project or global level.
If you need a starting point, I have a script that updates build numbers I can share.
Related
On our TeamCity build server every project now specifies the deployment repository either using the command line argument -DaltDeploymentRepository or <distributionManagement> in the project's POM file.
However we are planning to move to Nexus 3, and there would be considerable amount of work to make sure that all projects are configured correctly. There is also the fact that the deployment procedure has to be communicated with every developer.
Is it possible to specify the Maven deployment target in settings.xml or other so that unless otherwise specified any project that does a deploy on TeamCity will get deployed to the correct repository?
...in settings.xml...no:
Servers
The repositories for download and deployment are defined by the repositories and distributionManagement elements of the POM.
...or other...yes:
Create a (or, if already existing, use the) parent POM from that all your projects inherit.
I figured out another solution: TeamCity meta-runner. By producing a working build you can extract a meta-runner which is kind of like a build-step macro.
If you first get the deployment working you can extract a meta-runner using Actions->Extract meta-runner... in the TeamCity build configuration.
This shows an editor for the XML that specifies the build-runner. Remove all the non-deployment specific build steps, and you can provide build step parameters in the meta-runner/settings/params block. You will probably need to add pomLocation and the specify %pomLocation% in the build step's <params> block.
I have C# project in TFS + TeamCity (TC). Now i have tag 1.0, trunk 2.0 and TC build config for 2.0.
I need to enable build for 1.0 from tag (and for future tag 2.0, 3.0, etc..).
I've created common TC project MyProject with all necessary configurations. Now i added subproject '1.0 release brunch'. And i'm goning to copy all configurations from root project + change VCS roots of that configuration. When i'll have to make tag 2.0 i'll create subproject '2.0 release brunch' and copy all root configurations to this subproject and change VCS root.
Is this normal steps to support previous projects? Should i use configuration templates or something? Each project contains 5+ configurations to build CI and Full Release builds with all changes, E2E testing, etc. So this is not just copy configuration to the subproject and change VCS root. This seems will be a tuning for every project. And i'd like to automate this as much as possible.
One way of handling this situation is to create a single build configuration and use a parameter in the VCS trunk. So instead of using a VCS root of
https://server/svn/MyProject/trunk/
you would instead use
https://server/svn/MyProject/%TagPath%/
Then create a configuration parameter in the TeamCity build configuration called TagPath and simply set it's value to trunk or tags/1.0 or whatever.
The one caveat to be aware of no matter how you do this is that you will have problems if your build process changes in the future and in that case you would probably end up creating separate "old" and "new" build configurations.
You can use Build configuration template for this. You can create the template at the root project level and then use it for sub projects.
Look at the "Redefining settings inherited from template" section in the link below on how to use parameters to change the values at the sub-project level.
http://confluence.jetbrains.com/display/TCD8/Build+Configuration+Template
Actually I see two alternatives how can I deploy my project to NEXUS:
Configure distributionManagement and deploy-plugin in pom.xml. That in jenkins I should only call mvn deploy and my project will be deployed to the environment
Create in Jenkins Post-build Actions -> Deploy artifacts to maven repository, where I can set repository URL, repository ID and so on
Question
What is pros and cons of each approach comparing with one another?
If you are configuring the deployment in Jenkins build configuration you are doing two things
you are separating the deployment from the project itself and therefore potentially can have different deployments for the same project
you remove the deployment setup from your version control setup/your source code
If you are leaving it in the pom using the default Maven setup you can run deployment of the project without modification from the commandline on any machine that has the credentials set up correctly. This can greatly help wit troubleshooting and it makes the setup independent of whatever CI server you use.
Both approaches as well as more custom setups like using the Artifactory Build Integration or the Nexus Staging Maven Plugin usage are fine. It will mostly depend on what you are aiming to achieve.
Personally I believe that the configuration should not be isolated to Jenkins and should remain with the project in the pom. But that is just my 2c.
Thanks for adding the Artifactory tag, now I can give you one more option - Artifactory Build Integration. With Artifactory Jenkins plugin you can configure your deployment options (target repository, whether or not you want to deploy build information, environment variables and custom properties etc.) without polluting your developers pom with ci-eyes only information.
I started using JRebel just moment ago. In my current setup launch JBoss instance from Eclipse and I use command line maven to deploy. I was wondering whether it would be anyhow possible to avoid redeployment when I need to change from test-A profile to test-B profile. Profiles are used here to set several configuration values.
If you're using JRebel, you should forget about Maven as there's no need to build the package after every change.
If profiles are used only for configurations, why not to make the changes to the configuration files directly? Depending on the nature of the configuration files these can be handled by JRebel. What are those configuration files?
You can't change profiles for already running Maven instance. But you can activate specific profiles on Maven startup using system properties.
I am setting up a CI system using Jenkins for Maven based projects. I was wondering whether there is a way to specify a build configuration which would be common for all the projects deployed on Jenkins.
For instance, I want all the projects to generate JavaDoc's hence I require the maven-javadoc-plugin in maven pom. As I understand, this can't be added to the settings.xml file. And I don't have access to the super pom. And editing the super pom isn't a good idea anyways.
What is the best way to add a common build profile for all the projects?
Corporate POM, that's what I was looking for.