I have a java-maven project named clarity which has one pom.xml file. we recently created a bitbucket account and created two branches one for development team and one for reporting team. It's like two teams make changes to their own branch. Now I need to configure jenkins for running separate sonar reports for this two branches with one project itself, how do i that. Should I change the pom.xml file or need to specify something in jenkins jobs. Please mention clearly as I am new to this jenkins config.
Any help is appreciated, Thanks :)
You should differentiate the two copies using the sonar.branch analysis parameter, which you should be able to pass into the Maven analysis on the command line using, E.G. -Dsonar.branch=reporting
Related
I need to scan all springboot projects from my github organization which uses a particular dependency(say platform-core) being used in pom.xml.
Need to create a freestyle/maven stand-alone job which should scan pom.xml of all 100 odd projects from github and prepare a list which project has the mentioned dependency. mvn:dependency-tree gives the list, but for 100 projects need to understand the scalability , since this may involve downloading each project, run mvn:dependency-tree and search through the console output?
Can anyone help is there any way to achieve it?
Note that for public repositories, GitHub has introduced a feature for Listing the packages that a repository depends on
(meaning, without you cloning the repo and running mvn:dependency-tree)
But there is no API I can see which would query that list remotely (beside scraping the page)
So cloning and running (possibly in parallel) remains the one avenue you have the most control.
I am using SonarQube to analyze my code before uploading to Gerrit and as a step in the review process in Gerrit. The same code is analyzed twice and I have two projects, e.g. "development-project" and "gerrit-project" in SonarQube. I then sometimes marks something as "Won't fix" or " False positive" etc in my "developpment-project". I would like to move that to the "gerrit-project". Is that possible?
I was in similar situation and I created simple command line tool for copying Won't Fix and False-Positive resolution types from one SonarQube project to another. A bit clumsy solution, you need to run it after each merge, but better than manually resolve the same issues in two or more SonarQube projects.
You can find the tool on GitHub - https://github.com/HonzaTau/SqCopyResolution
Unfortunately you cannot. There is information, in SonarQube documentation, that projects created with sonar.branch parameter are treated as independent* projects.
*independent - not associated with any other project
http://docs.sonarqube.org/display/SONAR/Local+and+Branch+Analysis:
[...] you add the sonar.branch=[branch key] analysis property to the
release branch to create a second, independent project in SonarQube.
I'm extremely new to TeamCity and need to copy files from one TeamCity agent to another. I'm basically looking for some conceptual direction so I can start researching on how to accomplish the following:
Currently have a TeamCity Agent which builds program and creates corresponding artifacts. I need to copy these artifacts to another TeamCity Agent machine.
I'm getting acquainted with the build steps, we are using a commandline build runner. So I'll need to setup the build step for copying files via commandline--any hints on how to get started is greatly appreciated.
I apologize for any conceptual or term errors. I guess this is why I'm posting this question.
Kme,
In case you want to re-use the results of one build in another (e.g., run tests using results of compilation), you should take a look at two things:
Publish your build artifacts to server (more details here)
Download an artifact from server before build starts (more details here)
This will allow TeamCity to ensure that artifacts arrive at correct agent at correct moment of time. Also TeamCity will track usages of such artifacts.
I would like to use some build parameters from Project 1 in Project 2. I know that I can make Project 1 a dependency of Project 2 and then access its build parameters as described in Dependencies Properties, but I do not want Project 1 to be built in response to a build of Project 2. For example, suppose I want Project 2 to be built nightly, while I only want Project 1 built monthly.
Is there any way Project 2 can access Project 1's build parameters under these conditions?
I would use a build configuration template that is shared between the two projects.
This means you can share properties between the projects, but also override certain ones in each individual project.
We use this for hourly builds that are not tagged and nightly ones that are tagged.
Then use a different build trigger to set one off nightly and the other monthly.
EDIT
I'll just expand slightly as a result of your comment.
In TeamCity we have 2 build configuration for the same project. One that builds on every check-in to give developers quick feedback on their contribution (build within 15 minutes). It does the following:
Builds the project in Debug
Runs all unit tests
Checks results of build into Subversion
The other configuration runs every night at midnight; it build everything and as a result takes a long time (around 45 minutes). It does the following:
Build the project in Debug and Release
Runs all unit tests
Builds Sandcastle documentaion
Checks results of build into Subversion
Grabs the Sandcastle output at an artefact so developers can easily download it.
As you pointed out this isn't as straightforward as one would like; however you can use the following to achieve it:
We use the Autoincrementer to share build numbers between the two configurations (they both increment the same build number when built).
We have a property on template that defines what artefacts to collect and is referenced from the artefacts field. The property is overridden on the second build config to define the sandcastle output to grab.
Sharing VCS Roots is mentioned on the documentation. Both our builds get the source from the same place, and tag the results to the same place. One VCS is most definitely all we need.
Bit of a long edit but I think it goes exactly on the lines of what you're trying to achieve. I appreciate I should have included this in the original answer.
HTH
Dependency is different from Build Triggering in TeamCity. If you make one project dependent on another ( artifact dependency ), it does not mean that the the latter will trigger the former.
Even when one project has been defined as dependent on another ( and also, even if not ) you have to specify explicitly the build trigger ( in this case a Finish build trigger ) for the dependent project to be triggered.
In my CruiseControl instances, I have version controlled the ccnet.config file.
When I want to update CruiseControl, I run an "update config" job which fetches the config from version control.
In this manner, the very build process of a release is configuration managed.
I am wondering how to achieve these goals effectively under TeamCity.
I try to keep what ever CI I am using as light as possible and put as much of the running of the build into an msbuild or nant script including running tests, code coverage, etc.
The benefit of this is:
The build file is version controlled.
You can run the script in any environment.
Easier to move between CI environments.
Everyone becomes responsible for the build.
This has been introduced in TeamCity 9. Also answered in another post:
Version control (e.g. in TFS) build configuration for TeamCity - is it possible?
I've been wanting a way to source control TeamCity config for a long time. I ended up writing a Windows Service which monitors the configuration directory and commits changes to git.
The project is on GitHub: https://github.com/grenade/teamcity-config-monitor
You might try looking at the folders that are backed up prior to upgrade (or when restoring team city) as those represent the configurations and changes you've made since initial installation.
http://confluence.jetbrains.net/display/TCD4/TeamCity+Data+Backup
Some of the relevant data is actually a database, (and in fact the documentation advises you to point team city to a real database like mysql instead of the default embedded database it uses)
You could try checking those into SVN, but you'll want to stop team city for any check-in actions.