Is there a way to prevent jenkins to produce build logs in successful builds. I basically do not need the logs when the build is successful. However I would like to have the builds only in the failure builds.
Thanks
Edit: Please aware that I do not want to remove the builds. Just the logs of them.
Related
We're in the process of migrating to Jenkins pipeline. We use Jenkins to update the build status of our branches/PRs in Bitbucket.
One of our merge checks in Bitbucket is "Check the last commit for at least 1 successful build and no failed builds". This means that we can't merge unless there is 1 successful build of the latest commit on Jenkins, and no failed builds of the latest commit.
Sometimes, Jenkins builds fail for reasons unrelated to the code and the build is fine next time you run it. However, this means that the branch can't be merged as there has been at least one failed build.
To get around this, we were previously able to tick the box in the build status notifier plugin configuration that said "Only show latest build status". As of yet, we're unable to find any equivalent way to configure this in a Jenkinsfile. Does anyone know if it's possible, and if so how?
This question is a duplicate of Multi branch pipeline with bitbucket build status notifier plugin in jenkins, but that question was never really answered.
It seems that your use case it's covered by the Build REST API of Bitbucket, and there is even a step-by-step example of your exact case, being last build failed for external reasons, and a new build succeeds
In order to overwrite the status of an already reported build, you will need to use the same commit sha and the same key
Regarding the Bitbucket Build Status Notifier, it allows you to specify a buildKey as an optional parameter. You should make sure to specify this parameter, and that the parameter is always the same for all builds of the same job.
That way, a new build of the same last-commit will overwrite the last one, as it will be using the same sha and the same key.
See the API section of the plugin documentation for additional parameters.
I use JIRA to store my my user stories and TeamCity to do my daily builds. I am trying to automate the generation of release notes (for only completed user stories) via the TeamCity build. Have you guys done this before?
Ok, I found a work around. here is the link to the steps
How can TeamCity generate Release notes from JIRA during a build
Enjoy!!!
Just implemented the TeamCity meta-runner which generates release notes with commits and tasks from the current TeamCity build, so you don't need to use JQL.
Give it a try.
https://github.com/olsh/teamcity-jira-release-notes/blob/master/GenerateJiraReleaseNotes.xml
I'm currently running a a build job on Jenkins that generates a bunch of CUnit testing exes. What I'd like to do is take those binaries and run them automatically on a bunch of other machines upon successful completion of the build.
For example: Run the build -> success -> trigger copy of EXEs to other machines -> run said EXEs -> gather output.
My question is whether or not this is possible to automate with jenkins? I'm not entirely sure the direction I should be going in. My best guess is to configure a bunch of other jobs that will trigger on successful completion of the Build job. These jobs will retrieve the files in question from somewhere, run them, and report back.
Any input would be greatly appreciated.
In the post-build actions of your build job, mark the generated executables as artifacts, then you can use the Copy Artifact plugin to distribute the test executables to another test job (or more than one) that runs a Jenkins build slave on the test machine(s). As you've mentioned, you can configure a successful build to trigger the test jobs. Based on other answers, it looks like CUnit generates an XML report of the test output that Jenkins can parse, so in the test job's post-build actions, configure the location of the test results.
From a management perspective, it is easier if there is one test job because you don't have to figure out how to partition the executables and you can read the results in one report. But depending on your use case, it might make more sense to have separate test jobs if the tests require different environments or if it makes sense to partition the test results.
I have successfully setup a CCNet web dashboard and everything is working fine has expected.
And i have triggered a force build from CCNET and it ran successfully with out causing any error. but, the problem what i am facing is that, whenever i'm triggering the build from CCNET dashboard (Force) it's keeps on to build continuously again and again.
Actually it should stop the build automatically right after the success of the latest build.
can any one help me out, how to stop the continuous builds ????
Thanks in Advance !!!
Indeed, check your triggers.
See "Next Build Time" column on the dashboard. If it has date/time then project has a trigger. If not - you'll see "Force Build Only".
Check your build's triggers. You've probably got it set to force a build at a very frequent interval.
Let's say I have one TeamCity build configuration depending on artifacts taken from another.
It is possible to publish artifacts while build is in progress in TeamCity.
My question is: is it possible to trigger build when all necessary artifacts are available even if builds that are providing these artifacts are still in progress?
The purpose of this is to speed up builds a little.
Thank you!
TeamCity, as far as I know, only has the option to trigger on finish of another build configuration, not after publishing artifacts which as you say you can do while the build is still in progress.
Let me ask you another question:
Since whatever you are doing in the build after the publication of the artifacts didn't of course stop you from publishing the artifacts, can't you extract that part out into another build configuration and then have that part fetch the artifacts from this one? This way you can make whatever build configuration you wanted to trigger as soon as you get the artifacts, trigger, well, as soon as you get the artifacts.