I want to collect the build metrics for a maven build (metrics like total time taken for the build, status of build SUCCESS or FAILURE, test results etc.,) and store it for analysis. All these information are available in the log but i need to collect it at the end of the build and call a service with the data.
This feature should be available where ever maven build is done. so it should be associated with the lifecycle. But i am not sure whether maven has any hooks to tap to get this kind of information.
-
Kamal
You might want to look into Continuous Integration, which will build your project everytime you commit to the repository. I personally like Jenkins, where you can install the Global Build Stats Plugin which I think will cover what you want to do
I found a way to profile the maven build in developer machines.
For Maven 3 and above, it exposes the events through EventSpy API. An example profiler is available at https://github.com/tesla/tesla-profiler . so we implemented our own profiler and it logs the data to the central server.
For Maven 2.x, there is no easy way. I modified Maven to expose the events and wrote listener to track the data
#Kamal's answer requires you to modify your local Maven installation which is not a portable solution.
Here is a maven plugin which collects execution times of each plugin and saves it as an HTML report. The plugin utilizes Maven's core extensions feature which was introduced in 2015, so that you don't have to modify your Maven installation.
https://github.com/jcgay/maven-profiler
Related
I have Jenkins version 2.7.1 running on a Windows 7 machine. It is successfully pulling code from a subversion repository and running tests. I have the test jobs set up for the development branch of each project only.
We periodically make stable releases of the projects in jar files with version numbers. I would like to have Jenkins be the repository manager for those stable releases. These are made by hand - There is no Jenkins job making or testing stable releases. The projects do use Maven.
Each stable build is tagged in the subversion repository, so it could be made again on demand if needed.
I downloaded the Maven repository server hoping to make this fit the purpose. I read the documentation that's provided, but it's pretty terse. As I understand it and have it configured now, this appears to have a couple of issues:
If I go to jenkins-ip/plugin/repository/project, it has made directories there that expose the names of all of my projects, which seems undesirable. (Here jenkins-ip is the IP where I access Jenkins on my local network.)
On the other hand, there's nothing but empty directories under these projects, so they're currently useless.
These projects all correspond to the continuous testing of the development branch. There's no apparent way to get the stable builds into the hierarchy. (It doesn't seem efficient to create a job for each stable release...)
Is there anyway to get Jenkins (with this plugin or through another method) to be the repository manager just for the stable builds? I know that I can start a different repository manager like archiva, but it would be ideal to use Jenkins since it's already running and it seems to claim capability for this function now.
To use Maven repository server you have to build the project on Jenkins.
Then the plugin will expose all archived artifacts as maven repo.
Note you need to use a "Maven project" type for it to work (freestyle is not supported)
There are several plugins that will help you manage building from multiple tags, however not all of them work with "Maven project" type.
You could also try Jenkins pipeline (previously "Workflow") or the Job-DSL plugin.
A simplest solution would be to have a build parameter specify the tag name (then checkout e.g. ^/tags/projectname/${tagParam}), but you have to figure out how to trigger the job then.
We currently use SilkCentral Test Manager (SCTM) integrated with our source control system via SCTM source control profiles. However, we would like to explore integrating with build artifacts checked into Maven's remote Nexus repository instead.
The idea being that the application-under-test is built and checked into Nexus along with the automated tests only if the build and the tests pass. Therefore, when QA is ready to run tests from SCTM (manual or automated), there is a well-defined combination of application build artifacts and test build artifacts in Nexus that present a more reliable target for SCTM as compared to getting the latest code from the source control system.
All of this is more relevant during active development when the code and the tests and changing daily and the builds are snapshot builds rather than formal builds with tags in the source control system that SCTM could use.
SCTM apparently has support for both universal naming convention (UNC) and Apache virtual file system (VFS) and either of these should potentially be utilizable to point the SCTM source control profiles to Nexus artifacts rather than raw source code. However, I wanted to check with the community to see if there's a simpler approach. (For example, I noted the existence of a Hudson SCTM plugin.) Also, I welcome alternative thoughts and ideas.
There are probably many solutions for solving this, I'd try the following:
Manage the build/first test/publishing steps in Hudson/Jenkins.
For example by modelling it with dependent jobs, the publish job is only triggered if the tests pass. There are also more advanced gatekeeper plugins available (for example a Downstream Ext plugin) which might solve this even more comfortable.
Once the publishing is done, use the Hudson/Jenkins-Silk Central plugin to trigger the executions on Silk Central. There, instead of using UNC or VFS, I'd rather use a setup script which pulls the artifacts from the repository and prepares everything for the tests. This would allow you to use something Maven/Nexus aware to pull the correct artifacts from the repository, instead of somehow trying to make it accessible via UNC or VFS.
We are trying to install a CI Platform with (Jenkins,sonar,eclipse ...).
So that every developer can make analysis on his code before commit, I'm wondering between two alternatives :
running local analysis with the sonar plugin.
install the different plugins that sonar use (findbug,pmd,checkstyle ...) and configure them to meet the sonar configuration.
I'm not sure which alternative to use? I used to work with findbugs,pmd, checkstyle in eclipse and they look great.
Can you tell me which is the best alternative?
Thanks in advance.
Regards.
With Sonar plugin you can manage the violations like:
Create a review
Mark a violations as false positive or fixed
View the hot classes and hot violations
View yours reviews
If you use separate plugins you have to go sonar web to do that.
The great advance of sonar is the reviews.
Other question is how many projects you have and will have. I currently work with more than 70 projects and many profiles. Is more simple to me run analysis with one plugin, because I need just add the server and find the project. With other plugin you need add the link for each project in each plugin configuration.
Why not install the Sonar Eclipse plugin?
This was designed to solve the following problems:
Sonar does not support parallel analysis of the same project. This issue rules out the option of each developer running Sonar locally. (See SONAR-2761, SONAR-3306)
You don't really want developers uploading metrics and source code into the Sonar database. They could be working on an uncommitted workspace and would therefore cause both inaccuracies and confusion if Sonar is being used for code review.
Sonar is really designed to be run from a continuous integration server (like Jenkins), building code that has been submitted onto a shared codestream (or branch)
The big advantages of using the Eclipse plugin are:
True local analysis, no updates of the Sonar database
Configuration of the other tools is retrieved from the Sonar server and jars automatically downloaded.
Centralized management of Sonar quality profiles
I'm a Maven noob currently working with Maven/Jenkins to perform some downstream jobs on the back of a release task and my team has hit a problem.
What we are trying to achieve is to pass in the version tag into the downstream jobs once the main build has been executed. We had been trying to achieve this using the M2 plugin, but it appears to execute in a Build->Downstream Jobs->Release cycle, and we need to have a Build->Release->Downstream Jobs pattern.
We therefore decided to create a separate job using the build step to perform the release a as a Goal. Here's the directives we are using to achieve this:
-Pdmt -Dresume=false release:clean release:prepare release:perform -DautoVersionSubmodules
A consequence of abandoning the M2 plugin for this job has been that the prompt requesting the version number is no longer appearing. Subsequently, we've been trying to achieve this via the Post-build Actions, and passing in pre-defined parameters. The issue for us here is knowing how to pass in a dynamic parameter based on the previously executed job.
An alternative angle we were looking at was specifying a properties file that the main job could tokenize prior to it's usage in the downstream jobs.
Does anyone have any advice on how we might achieve this workflow, or if it's even possible?
OK, JFTR it looks like it's outside of the scope of the maven release plugin:
To answer the question I had to enumerate some of the assumptions made by the Release
plugin. I can tell you about these baseline assumptions and you can decide whether or not > something like the Maven Release plugin is appropriate for you.
What are these assumptions?
Your codebase is going to be versioned and released as a “unit”. What
does this mean? This means that you are going to be releasing an
entire project at once with all of its submodules. [sic] In Github it means that the Maven
Release plugin is going to operate on an entire repository.
The complex relationship of the repositories, releases and resultant artifacts prevent us from automating the task in the manner described in the question
My TeamCity's nightly build produces more than 130Mb java doc as Build Configuration artifact.
I have to share these artifact for other teams(developers), but javadoc every time has another one URL(I know that it's possible to get it like .lastFinished), and get's new place on Build Machine.
Is it possible on each build replace old artifact with new one because I don't need need previous versions? And have independent from build version URL for accessing.
You can configure TeamCity to delete artifacts after the n-th subsequent build - set this to 1, and it won't keep much for you. Look under Administration at Build History Clean-up Policy.
And the independent from build version URL should then probably be the .lastFinished one you mention.