Do I need to change the ci/cd pipeline in any way if I added a plugin to sonarqube?
There is a project with a working ci/cd pipeline, where there is a sonar step. I want to add the findbugs plugin to it, but do I need to change something in the pipeline itself later? Or will the plugin pull itself up and work?
Related
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.
I have a multi-module maven project and have it's modules as Sonar components.
Is it possible to set alerts separate per module/component, or Sonar considers the whole project? If not, what's the best way of having my maven modules as separate projects in Sonar, so that mvn sonar:sonar is only executed once. I use cobertura for report generation.
At the moment of writing this answer, that feature is not supported by Sonar.
If separate metrics needed you need to create a separate project and trigger a separate build from Jenkins and providing specific pom.xml file for desired module.
TeamCity has a feature which will publish the Build Information to artifactory always.(by default). If we check that publish build info option(in step 3 - i'm using gradle as Runner), The published information will be recorded in Artifactory so that, we can trace back to the build which produced the artifact.
Now i want to disable publishing build information if the build is person build. How to achieve this?
Thanks.
This isn't possible without customizing either the TeamCity Artifactory plugin or the Gradle Artifactory plugin.
Build Info descriptor deployment is currently decided upon using a boolean variable, but customizing either plugin to do what you need should be fairly easy.
I was wondering if there is a Hudson/Jenkins plugin that ties repository artifacts to the build that created them? I was looking at the question "remove artifacts from nexus repository" and thinking that deleting a build in Jenkins should also offer the option to remove the artifacts the build created.
We are currently running Jenkins 1.447 and the Nexus Open Source 1.9.2.3. Our Jenkins builds create artifacts in our Nexus repository using the maven deploy goal. I appears that once those artifacts have been deployed, there is no similarly automated mechanism to remove them. We would like to tie the Jenkins build to its Nexus artifacts. I figure if we have decided to remove the build from Jenkins, we have no use for the build and therefore, have no need to store the artifacts for that build either. We would like deleting the build to trigger deleting the Nexus artifacts.
If there's nothing available I figure I could start writing something, but I wanted to check and see how others handle this.
you can use the REST API from Nexus to build your own Jenkins Plugin that does that Job for you. You could store the Jenkins Build Job number using the Nexus custom-metadata plugin. Once the build is deleted you can have your custom Jenkins Plugin delete all artifacts in Nexus that have that build number in their metadate. I had a similar Problem and wrote a custom Jenkins Plugin. Have a look at the tutorial and the source code on github. It should be pretty straight forward.
Tutorial:
http://blog.codecentric.de/en/2012/08/tutorial-create-a-jenkins-plugin-to-integrate-jenkins-and-nexus-repository/
Sourcecode:
https://github.com/marcelbirkner/nexus-metadata-plugin/
You can purge artifacts from a local repository via the maven-dependency-plugin.
If you have a release it does not make sense to number it based on the numbers of the build server. The usual use case is to use SNAPSHOT's for exactly this purpose. Furthermore the usual use case is to delete SNAPSHOT's based on a scheduled task after a time from Nexus but releases will never be deleted from Nexus.
Since you know the name of the release, you could build a custom job or trigger to use a wget command to delete the artifact from the nexus repository.
As the proper user in Nexus you do have the ability to delete release artifacts, not just SNAPSHOTS.
We have a Build that compiles and creates an artifact. Then we have another Build that uses the last Compile build and Deploys it to the proper environment. Once that is complete, I have to go and Tag the build in TC that it was pushed to the environment. Is there a way that I can tag the Compile Build that is was deployed using the Deploy Build?
I'm not aware of an easy way to do this (i.e. through a TeamCity configuration setting) but you probably could accomplish this using the REST API from your build script.
If you are using TeamCity 6 or above because you have a build dependency chain from the Deployment Build to the Main Build either through artifact dependencies, snapshot dependencies or both you can just tag your Deployment Build. This is because the UI will show you a tree view of the dependencies that the deployment used and you can navigate to the actual build.
One thing you can do, and in my opinion should do, is to tag your source control from TeamCity if you are using a source control that supports tagging/labelling. You should probably set your Deployment Build up with a snapshot dependency as well as the artifact dependency, especially if your build files are in the same repository. On your Main Build you should get TeamCity to label your repository on a successful build with something like "build-1.2.3.4". Then on your Deployment Build you should get it to label the repository after a successful build with "deployed-1.2.3.4". If you deploy to different environments then you can get it to label the repository accordingly.