I am working on a CI system with Jenkins. But now I got a problem. I need to do the following steps.
1:Jenkins build
2:Deploy to Tomcat
3:find a way to send the build parameters (Job Name, build number...) to a web server (I am using REST now).
4:Web Server trigger testing system.
5:Jenkins get the result from testing system.
6:update build status
7:send emails.
I have problem with the step 3. I need to send those info after the deploy. I am thinking a way as following.
write those parameters to a file during build step, then call a script or Java problem to process the file and send out those info by REST.
But that is ugly. Is there any better ways to do it?
Side questions
Can groovy do this?
How to import groovy http-builder library to Jenkins?
I found a walk around solution.
1: ran echo command during the build to get the build ID and print to log.
2:wrote a small Java program to get the JSON response of the build then sent the necessary info as rest request to the server you set. The program is like a message forwarder.
3:in post build actions, use groovy post build to fetch the log then call the Java program.
Related
Our code building process is done via an http server which starts the build process after receiving a project uuid from the build command. Once the server starts the compilation, GCC compatible output can be fetched from it.
Note: only my extension is aware of the project uuid which is different per workspace.
AFAIU I can implement it by:
programmatically adding a task which will call a script with the correct workspace uuid. Is this possible?
Having my extension manage the build process. This seems to be far from supported.
Bottom line, I'm trying to avoid asking the user to add anything to the configuration files and I want to completely manage the build process.
Thanks!
As I didn't find a suitable only vscode solution I did the following:
Defined a helper script which I executed as the task. The helper script was respojnsible for the communication against the HTTP server.
I registered the task using vscode.workspace.registerTaskProvider API, and made sure to register it only after figuring out the UUID.
Then in the task itself I executed the helper script.
(A nice task register example can be found here: https://github.com/Microsoft/vscode-extension-samples/tree/master/task-provider-sample)
I am currently in a process of setting up Jenkins-CI for my Scala/Akka project.
I managed to create build that is integrated with BitBucket and executes builds when new pull reuqest is created/old pull request is updated.
As a testing framework we are using Specs2 which is also integrated with Jenkins by using JUnit post-build action. Now I am wondering how to properly execute e2e tests in my build.
Basically in git repository we have 2 projects, lets call them main-project and rest-tests. rest-tests contains e2e tests that are written using REST-assured library. To execute them I need to start main-project application (which uses Spray library to set up HTTP server) and then execute test task in sbt project of rest-test.
My idea was to execute main-project startup script (generated by sbt-native-packager) whith something like this:
$WORKSPACE/main-project/target/universal/stage/bin/main-project & echo $! > /tmp/main-project.pid
then execute test task of rest-tests project and finally kill process with PID that is saved in /tmp/main-project.pid file.
The last step should be implemented using https://wiki.jenkins-ci.org/display/JENKINS/Post+build+task because if some rest-testswill fail the next steps of build will not be executed (or at least that is what I am thinking) and I could end with my instance of application running after the build is finished.
This is first time when I am setting up CI system and my solution seems to be a little hacky (at least to me). I am wondering if there is a better/more idiomatic way of solving my problem of running e2e tests which require another application running.
I am using a Perl script to trigger a build in Jenkins using LWP modules. This works but after executing the job, I would like to parse the console output.
Is there someway to get this?
Log into Jenkins and take a look at the bottom of the webpage near the right hand side and click on the REST API link. This will give you information about the Jenkins RESTful API which is a great way to pull information off of Jenkins once you understand how to construct the URL.
And, here's how you get the console text:
$ curl "${JENKINS_URL}/job/${JOB_NAME}/lastBuild/consoleText"
You can use Perl's various LWP modules to talk to Jenkins.
Use the Log Parser Plugin for Jenkins. Read the page number 24 here for the configuration and other details.
If you want to access the log from another Jenkins job that runs on the master, you can do it from a chained (child) job without needing to send an http GET. See https://stackoverflow.com/a/41974193/1580627.
I am creating a screenshot when my NUnit end-to-end test fails and I am trying to publish it with TeamCity (build agent and server both running on Windows) using the following service message (as described here) which I am writing with Console.WriteLine from an NUnit test:
##teamcity[publishArtifacts 'C:\BuildAgent\work\xxxxxxxxxxxxxxxx\Path\To\My\Stuff\fail.png']
I see the line in the build log:
------- Stdout: -------
##teamcity[publishArtifacts 'C:\BuildAgent\work\xxxxxxxxxxxxxxxx\Path\To\My\Stuff\fail.png']
But TeamCity is not picking up the file, or at least it is not showing up in the build artifacts. How do I make this work?
Try using relative paths. Teamcity should resolve them against build working directory.
You can try Console.Write instead of Console.WriteLine (see below).
Anyway, I guess TeamCity don't trap these messages because they are 'test reports' and appended in the buildlog as text output.
My feeling is they are not parsed and then not interpreted by the Build Script Interaction behavior because of the way they are flushed into the build log.
From the Build Script Interaction (TC 7) :
Service messages are used to pass commands/build information to
TeamCity server from the build script. In order to be processed by
TeamCity they should be printed into standard output stream of the
build (otherwise, if the output is not in the service message syntax,
it should appear in the build log). A single service message should
not contain a newline character inside it, it should not span across
multiple lines.
You should put your test artifacts in a specific folder and delay the publish after the tests.
Note that if you don't need to resolve artifact dynamically, you should use the simpliest way : the Artifact paths in the build configuration general settings.
Use the NuGet package provided by JetBrains, this takes care of all the subtleties
NuGet Install TeamCity.ServiceMessages
On GitHub: https://github.com/JetBrains/TeamCity.ServiceMessages
I have some integration tests that get kicked off by TeamCity on a successful build. I have had success using the TeamCity REST API in order to tag the build as passed or failed, but would actually like to mark the build status as passed or failed (in the same way builds are failed due to compilation or unit test failures).
The documentation for the REST API is pretty sparse. Is it just not possible to do this through the REST API or is it undocumented?
Clarification:
Current process is as follows:
"App" TC Build configuration actually builds the application and runs the unit tests.
"Test" TC Build configuration depends on "App" configuration completing successfully. If "App" builds successfully (no compile or unit test failures), "Test" configuration kicks off, which pulls down the build artifacts and runs the live integration tests on the application. Prior to these tests being run, "App" configuration has a status of passing, since it compiled successfully and there were no unit test failures.
What I am trying to do is to change "App" config status to failed, if the "Test" configuration failed. Currently I am merely tagging "App" as passed or failed, but the actual build status is always passing. Essentially I am trying to get the change log or history to show the red X icon for a failed build, rather than the green check mark.
"App" and "Test" are 2 separate TeamCity build configurations. Since they are separate, Build Script Interaction, as suggested by #sharma, will not do the trick, since Build Script Interaction can be used to fail/update the currently running build configuration, whereas I am trying to update/fail a separate and already completed build configuration.
Why do we have 2 separate configs and not just run the tests from the main build? Speed of course! The integration tests take up to 10 minutes to run, and we don't want to slow down the compile cycle just because the integration tests are running.
Actually you can change build status even after build finished with the following non-documented request (you need buildId of build you want to change):
curl -v --request POST "http://your-teamcity-url/ajax.html" -u login:password --data "comment=Your reason to fail build" --data "status=FAILURE" --data "changeBuildStatus=buildId"
You should be able to do it through build Interaction scripts.
UPDATE: Look here, It should have "reporting messages for build logs". If you have following message printed to console in which ever application build you are running. The teamcity build will fail and show as error. If you change status to Failure it will still fail. You have more information on the link I provided. An example message you may want to printout:
"##teamcity[message text='Exception text' errorDetails='stack trace' status='ERROR']"
Look at this
So the answer to my original question, is it possible to use REST API to mark build as failed from another build configuration, is that it is not possible.
Per TeamCity support: There is no way to change a build status after it has been finished. This is not a limitation of REST API, this is just not implemented feature of TeamCity.
Here is a related feature request in our tracker: http://youtrack.jetbrains.net/issue/TW-2529
(I upvoted #sharma's answer and comments, as they were definitely informative, but ultimately not a solution to my problem.)