I have a TeamCity project that runs Jmeter via Maven in a build called "PerfRunner" under the project "Audit-Service-Performance". When it runs Jmeter produces a target dir with a report html file, index.html.
I want TeamCity to create a report tab with the latest report from the latest successful.
Folder structure relative to artifact:
target
-jmeter
--bin
--lib
--logs
--reports
---jmeter-deng-audit-standalone_time_stamp
----index.html
--results
--testFiles
The problem is that the time_stamp in meter-deng-audit-standalone_time_stamp is auto generated and therefore changes with each build.
When I try to create a report tab I do a project or build report tab I tried:
target/jmeter/**/index.html. But it doesn't generate the report tab.
The only way I can get it to work is if I address a static file for a particular build which of course wont be the latest once a new build is run.
The MVN command runs clean. How can I make it dynamic?
You need to publish this index.html page as the build artifact. If you want to share the page with the others you can go for one of the following patterns of accessing build artifacts:
/repository/download/BUILD_TYPE_EXT_ID/.lastFinished/index.html
/repository/download/BUILD_TYPE_EXT_ID/.lastSuccessful/index.html
/repository/download/BUILD_TYPE_EXT_ID/.lastPinned/index.html
/repository/download/BUILD_TYPE_EXT_ID/BUILD_ID:id/index.html
/repository/download/BUILD_TYPE_EXT_ID/BUILD_NUMBER/index.html
You can also consider using JMeter Teamcity Plugin - it adds Performance Statistics tab where you can observe performance trend for last builds
Check out How to Run JMeter Tests with TeamCity for Continuous Integration article for more information on how to configure JMeter to work with Teamcity
Related
I have a standard build configuration, ending with a simple ssh copy of the output files to a remote server.
The process wanted is simple:
The developper pushes the commit to production
Teamcity builds the product
The developper downloads the product from the remote server where build results are stored
The developper tests the product (end-to-end testing, testing setups etc, can't be automated at the moment).
If the product is okay, label the build that produced this output as the new version (let's say 3.2.1).
Teamcity applies the label, and moves the files produced by this build to a folder named after the label value (3.2.1 in this example).
Only the last step is missing, because I don't find any ways to connect on the tag action to trigger some sort of build action.
I already tried to link another build configuration to this one, but the issue is that it has to be triggered by the developper for a specific build ID, so the developper tests the output of a given build, if it's okay, he tells teamcity "Okay, release this build as version 3.2.1" and the build artifacts are persisted in a folder named 3_2_1 for instance.
How can we combine different build reports in team city?
Consider all builds are chained and final job will show report of all jobs in chain.
You can configure artifact dependencies from the last build configuration in the build chain to all needed build configurations. So all the reports will be downloaded by the last build configuration.
If the reports are in HTML format you can publish it as TeamCity artifact and configure Report tab to make the reports available as an extra tabs on the build or project level.
Another approach is to use XML Report processing build feature that allows using report files produced by an external tool in TeamCity. TeamCity will parse the specified files on the disk and report the results as the build results.
For more details see how to present data in TeamCity in the documentation.
We are currently running a Jenkins (Hudson) CI server to build and package our .net web projects and database projects. Everything is working great but I want to start writing unit tests and then only passing the build if the unit tests pass. We are using the built in msbuild task to build the web project. With the following arguments ...
MsBuild Version .NET 4.0
MsBuild Build File ./WebProjectFolder/WebProject.csproj
Command Line Arguments ./target:Rebuild /p:Configuration=Release;DeployOnBuild=True;PackageLocation=".\obj\Release\WebProject.zip";PackageAsSingleFile=True
We need to run automated tests over our code that run automatically when we build on our machines (post build event possibly) but also run when Jenkins does a build for that project.
If you run it like this it doesn't build the unit tests project because the web project doesn't reference the test project. The test project would reference the web project but I'm pretty sure that would be butchering our automated builds as they exist primarily to build and package our deployments. Running these tests should be a step in that automated build and package process.
Options ...
Create two Jenkins jobs. one to run the tests ... if the tests pass another build is triggered which builds and packages the web project. Put the post build event on the test project.
Build the solution instead of the project (make sure the solution contains the required tests) and put post build events on any test projects that would run the nunit console to run the tests. Then use the command line to copy all the required files from each of the bin and content directories into a package.
Just build the test project in jenkins instead of the web project in jenkins. The test project would reference the web project (depending on what you're testing) and build it.
Problems ...
There's two jobs and not one. Two things to debug not one. One to see if the tests passed and one to build and compile the web project. The tests could pass but the build could fail if its something that isn't used by what you're testing ...
This requires us to know exactly what goes into the build. Right now msbuild does it all for us. If you have multiple teams working on a project everytime an extra folder is created you have to worry about the possibly brittle command line statements.
This seems like a corruption of our main purpose here. The tests should be a step in this process not the overriding most important thing in this process. I'm also not 100% sure that a triggered build is the same as a normal build does it do all the same things as a normal build. Move all the correct files in the same way move them all into the same directories etc.
Initial problem.
We want to run our tests whenever our main project is built. But adding a post build event to the web project that runs against the test project doesn't work because the web project doesn't reference the test project and won't trigger a build of this project. I could go on ... but that's enough ...
We've spent about a week trying to make this work nicely but haven't succeeded. Feel free to edit this if you feel you can get a better response ...
In Jenkins/Hudson, it's quite ok to have many jobs. some for doing compilation triggered version control changes, some for running (unit) tests triggered by successful builds, some for doing more tests (integeration) trigered by successful earlier tests, some for deploying, triggered by successfully passing all tests.
Look at plugins like join, build pipeline, parametrized trigger and more to help out with this.
This will also allow things to happen in parallel, by using multiple nodes. Trying to cram everything in one job is not the way to go.
We use the build in coverage application in TeamCity 6 (about to upgrade to 7.1)
If we wish to see the code coverage (or other metrics) of a particular build it is fine as we can navigate to that build, but it would be great if we could pluck out a few interesting metrics from all/some of the current projects/build configurations and display them all together.
For convenience I would expect the new display to be accessible from within TeamCity itself, however if there are solutions that require a separate solution we could look at them.
If you want to compare a set of common metrics (e.g. code coverage) across different projects and over time then SonarQube is probably what you want.
You can integrate it with TeamCity by adding a sonar-project.properties file to each project and calling sonar-runner from a command line build step.
The group that I work in has standardized on Jenkins for Continuous Integration builds. Code check-in triggers a standard build, Cobertura analysis and publish to an Artifactory SNAPSHOT repo. I've just finished adding a new target to the master build file that'll kick off a Sonar run but I don't want that running on every check-in.
Is there a way to schedule a nightly build of a specific build target in Jenkins? Jenkins obviously facilitates scheduled builds but it'll run the project's regular build every time. I'd like to be able to schedule the Sonar build target to run nightly.
I could, of course, create a separate Jenkins project just to run the Sonar target on a schedule but I'm trying to avoid that if I can. Our Jenkins server already has several hundred builds on it; doubling that for the sake of scheduling nightly builds isn't very desirable. I looked for a Jenkins plug-in that might facilitate this but I couldn't find anything. Any suggestions?
Here's one way to do it, if you are ok with triggering the build using cron or some other scheduling tool:
Make the build parameterized, and use a parameter in your build file to decide if the Sonar build target should run or not.
Trigger the build remotely by HTTP POST:ing the parameter values as a form to http://[jenkins-host]/jobs/[jobname]/buildWithParameters. Depending on your Jenkins version and configuration, you might need to add an Authentication Token and include this in your url.
Authenticate your POST using a username and password.
wget --auth-no-challenge --http-user=USERNAME --http-password=PASSWORD "https://[jenkins-host]/job/[jobname]/buildWithParameters?token=<token defined in job configuration>&<param>=<value>&<param2>=<value2>"
I am also looking for a solution for this. My current solution in my mind is to create 2 triggers in the regular build, one is the nightly build, another one is Polling SCM
In the sonar plugin configuration, it has the options to skip the builds triggered by the SCM change. Therefore, only the nightly build will start a sonar analysis.
I didn't get a chance to test it now, but I suppose this will work.
Updated on 12/19/2011
The above solution doesn't work if the sonar analysis is invoked as a standalone build step. To make the sonar analysis run conditionally, you could use the following 2 plugins:
Conditional BuildStep Plugin - this allows the sonar analysis to be run conditionally
Jenkins Environment Injector Plug-in - this allows you to inject the variables to indicate how the build is triggered.