I have some projects and i wrote an ant script to run sonar with this projects.
Its okay so far. But i need to show these projects under a top level project like sub projects.
I am using just Ant to run sonar and i just working on pure code not on binaries.
(I just need to analysis)
I could not find how i can solve this.
You have 2 choices:
Either those projects are really linked together, and you can configure an Ant build script to have a multi-module project that wraps all your projects => http://docs.codehaus.org/display/SONAR/Analyse+with+Ant+Task#AnalysewithAntTask-Analysemultimodulesproject
Or those projects are different (=> they have different lifecycles, they are functionnaly different, ...), and the best option is to use the Views Plugin => http://www.sonarsource.com/plugins/plugin-views/Overview/
Sounds like you need the Views-Plugin: http://www.sonarsource.com/plugins/plugin-views/Overview/
The SonarSource Views Product enables the creation of any aggregation
trees to regroup projects. Projects can for instance be grouped by
applications, applications by team, teams by department… Each level of
the tree is a View and offers all standard services such as dashboard,
hotspots, timemachine, drilldown… showing the consolidated measures.
Related
I am a bit confused about the differences of these two strategy.
Which is the guideline if I would like to share a java library among different java Apps ?
Regards,
S.
Not sure if a general guideline exists, but happy to share how we use the two in our company.
We use multi-project builds to organize the different parts of our product. For example, we have subprojects for the business logic, the rest api, the webapp, the mobile app, and the user manual.
In contrast, when working with software our product depends on, but isn't part of our product, using a composite build can be useful. For example, our product's webapp is based on a framework. For official releases of our product, we rely on the official releases of the framework only. However, in development we sometimes want to test a bugfix in the framework that has been applied to the framework's code base but that hasn't been relased yet. A composite build allows us to build the framework from source and run our product against that build.
I have CI setup with a few C# applications for service fabric.
I'm running the SonarQube scanner on a few projects with my CI tool, but I would like the data to be aggregated into one project in SonarQube, and have it separated by sub-folder/"component". However when I try to push results to one project, it just wipes out all the previous history of the past project.
For example I want my single sonarqube project to look like:
SonarQubeProject
-- serviceProject1
-- serviceProject2
where project1 & project 2 are analyzed separately. Is there a way to do this?
SonarQube 6.7 will introduce the concept of "Application"s as a paid feature (part of the "governance" plugin). This feature will allow the user to group several SonarQube projects into a bigger application.
Say I have the following sources defined in my sonar project properties file.
sonar.sources=src/client/app,src/server
Could I get SonarQube to use one quality profile for one path, and a different profile for the other?
Is this possible?
It's possible to apply multiple quality profiles to a project only as separate SonarQube projects with separate keys and analyses.
I.e. You'd have to analyze twice: once for each directory.
Your next question, of course, is how to re-combine the products of the two separate analyses. The answer is that that's only available with the Governance($) plugin, and Governance is only LTS-compatible (5.6 at this writing.)
BACKGROUND :
We are working on a few C projects, and the sources are in ClearCase. Each project have his own project ClearCase. My mission consists in putting all of them into Jenkins. There is no Continuous integration so far on this projects.
Some details, but very important :
The projects MUST be build with Windows AND Linux. Clients wishes.
The projects are developed on Eclipse, but no Maven, Ant... Only manual build with shell and batch. Already got some makefile to execute, using MinGW and GCC.
Same for the futures tests, they will be shell and batch scripts. They use real time, so, one test could be 3 minutes long. Average of 15 tests for each projects).
Here we are.
I'm thinking using a free-style project, with 2 slaves (Windows and Unix) for the build. The duration of the test are, now, not really a problem, they should be execute the night. So, maybe using slaves, don't know yet.
What do you guys think ? Got some advice before I get my hand dirty ?
Also, is it possible to have only one Jenkins project, with multiple sub-project with distinct ClearCase sources (and job and sub jub on each of this projects) ? (was looking to MultiJobs, matrix project, multi-SCM Jenkins: best way to build a project with sub projects, but couldn't understand or find the right method)
You do not exactly "put a project into Jenkins"
You define Jenkins jobs (start with one per project, you will worry about pipeline later). Those jobs must access the sources of your project in order to populate a Jenkins build workspace and execute whatever you define as a job (in a freestyle job, that can be any script in any language).
You will need the ClearCase plugin (or ClearCase UCM plugin of your projects are using UCM): that will allow your job to get the sources of the project.
Start by testing a job directly on the master (that node will be its own slave).
Once it is working, depending on the number of jobs and their frequency, you will scale by adding more slaves.
I have a relatively simple goal: I want to create a Cocoa application which doesn't have much functionality itself, but is extendable through plugins. In addition I want to work on a few plugins to supply users with real functionality (and working examples).
As I am planning to make the application and each plugin separate open-source projects (and Git repositories), I'm now searching for the best way to organize my files and the Xcode projects. I'm not very experienced with Xcode and right now I don't see a simple way to get it working without copying files after building.
This is the simple monolithic setup I used for development up until now:
There's only one Xcode project with multiple products:
The main application
A framework for plugin development
Several plugin bundles
What I'm searching for is a comfortable way to split these into several Xcode projects (one for the application and framework) and one for each plugin. As my application is still in an early stage of development, I'm still changing lots of things in both the application and the plugins. So what I mean by "comfortable" is, that I don't want to copy files manually or similar inconvenience.
What I need is that the plugin projects know where they can find the current development framework and the application needs to know where it can find the development plugins. The best would be something like a inter-project dependency, but I couldn't find a way to setup something like that in Xcode.
One possible solution I have in mind is to copy both (the plugins and the framework) in a "Copy Files Build Phase" to a known location, e.g. /tmp/development, so production and development files aren't mixed up.
I think that my solution would be enough, but I'm curious if there's a better way to achieve what I want. So any suggestions are welcome.
First, don't use a static "known location" like you mention. I've worked in this kind of project; it's a royal pain. As soon as you get to the point of needing a couple of different copies of the project around (for fixing bugs in parallel, for testing a "clean" build versus your latest changes, for working on multiple branches), the builds start trashing each other and you find yourself having to do completely clean/builds much more often than you'd want.
You can create inter-project dependencies by adding the dependent project (Add File), right click the Target and choose "Get Info," and then add a Direct Dependency on the General pane.
In terms of structure, you can either put the main app and framework together, or put them in separate projects. In either case, I recommend a directory tree like:
/MyProject
/Framework
/Application
/Plugins
/Plugin1
/Plugin2
Projects should then refer to each other by relative paths. This means you can easily work on multiple copies of the project in parallel.
You can also look at a top-level build script that changes into each directory and runs "xcodebuild". I dislike complex build scripts (we have one; it's called Xcode), but if all it does is call "xcodebuild" with parameters if needed, then a simple build script is useful.