Ive setup a Jenkins pipeline and defined it to trigger based on a Gerrit event which works fine.
However, every time a build is triggered, it leaves a comment in the gerrit
Jenkins Build.svc Patch Set 1: Build Started
and based on its success and failure, it leaves +1 or -1
How do I stop it from leaving the comment and giving +1/-1 from this particular pipeline ?
I've looked at Jenkins -> Manage Jenkins -> Manage Plugins -> Gerrit triggers but i dont see anything i can configure specific to this pipeline. it looks like they are global
In the Gerrit Trigger section open the Advanced settings and skip voting. That should work.
Related
Hoping to gather insight from professionals. My end goal is to trigger a jenkins build whenever a bitbucket pull request happens. If anyone could give me an ELI5(explain like I am 5) answer it would be greatly appreciated. Sorry if this is the wrong format, I am new to jenkins and stackoverflow.
What I have done so far:
Created webhook in bitbucket and gave the url to my jenkins job. example: http://jenkinsURL:8080/job/boulevard-dev/generic-webhook-trigger/invoke?token=myPull_Request_Token
Pull request webhook trigger
In Jenkins, under source code management I have: Source Code Management Settings. This is currently fetching a ton of branches, failing, then building the master branch when the job starts?
For build triggers, other stackoverflow articles have pointed me to the "Generic Webhook Trigger". https://github.com/jenkinsci/generic-webhook-trigger-plugin
I am not entirely sure how this generic webhook trigger should effectively be setup? Hoping someone has experience using it and could explain what is needed.
This is what have seen referenced in other articles.Build Triggers settings Build triggers settings 2
Questions:
What does a correct setup / example of the generic webhook trigger look like?
Currently, my job triggers when a change is made to master or merged to master, how can I specify to my job that I want the bitbucket pull request branch to be built?
Also, I found this, not sure if its related to my issue or not? https://jira.atlassian.com/browse/BCLOUD-5814
As per your requirement, you can trigger a Jenkins build whenever a bitbucket pull request happens by following the below steps, in my case, it's working fine.
Step(1) - Configure Jenkins
(i) Add your bitBucket repo and branch to source code management
(ii) On build Triggers setup Poll SCM to * * * * * for run every minute to check pull request from bitBucket.
Step(2) - configure Bit Bucket Hook
(i) Go to settings and add a new hook, now setup pull request trigger as per your requirement.
Step(3) - Make a pull request and see the new job automatically triggered on Jenkins.
I have a Jenkins pipeline that I have setup with a project I have on GitHub. Initially, I manually initiated a build each time I changed my code by clicking the "Build Now" option. However, I did two things to make my process easier:
I setup a GitHub hook to run the build I defined in my Jenkinsfile after each push to my master branch
I setup a periodic build to build every hour
I left my Jenkins for a day, came back, and everything, even from the dashboard, looks different.
For example:
My dashboard used to have these options:
New Item
People
Build History
Project Relationship
Check File Fingerprint
Manage Jenkins
My Views
Lockable Resources
Credentials
New View
The current dashboard only has three of those options:
People
Build History
Credentials
Also, when I clicked on my pipeline, the options I had were:
Status
Changes
Build Now
Delete Pipeline
Configure
Full Stage View
Rename
Pipeline Syntax
Whereas now, they are:
Status
Full Stage View
GitHub Hook Log
Git Polling Log
How can I change my configurations/settings to see the pages the way I saw them before? It seems I can't create any new items or change my current pipeline, which are things I may need to do in the future.
It turns out I wasn't logged in. I didn't think the initial pages would even show up if I hadn't been logged in, so I didn't even consider it to be a possibility. I logged in and all my issues were resolved.
I have a pipeline running, triggered by several gerrit review hooks.
e.g.
branch-v1.0
branch-v2.0
normally i receive my verifies accordingly to the result of the appropriate job run. E.g. run finished successfully with passed tests, i get the verified+1 back in my gerrit system.
My problem:
If there is running a job for verifying my gerrit change, a newer "verify job" of another change or patch, is always canceling the current running job. It doesn't matter whether the change comes from a different branch or not. Also no difference if the new change has something to do with the current one. The current running change is always superseded.
in the console:
In this case the job A canceled an older B and later A was canceled by a newer job C
Canceling older #3128
Waiting for builds [3126]
Canceled since #3130 got here
So, does anybody know how to avoid the canceling of the current running job?
I wanted to use the Multi-Branch pipeline (but i really do not know if this helps), but the gerrit plug-in is currently not supported by the Multi-Branch pipeline or the blue ocean project. As far as i know.
https://issues.jenkins-ci.org/browse/JENKINS-38046
There is a new gerrit plug-in in development, but there is no information when this will be available (or is 'production ready'). See the following comment in the issue.
lucamilanesio added a comment - 2017-08-18 15:40
Thanks for your support!
My jenkins jobs use testlink to store their test results. The testlink plugin changes the build status to unstable if a test has failed.
However I want the build result to be determind by Xunit plugin in a post-build action because with Xunit you can adapt a failure threshold.
The build should only be unstable if there are new errors.
I was hoping to do the following:
--test--
--testlink -> marked as unstable --
-- groovy scipt --> marked as succes --
build.result = hudson.model.Result.SUCCESS
-- xunit, checks threshold for unstable/succes --
However it seems impossible to change the build status back to success.
So now testlink marks as unstable, and xunit mirros that status.
Is there a way to work around this problem?
Unfortunately, I don't think Jenkins will allow you to do that without an ugly hack.
For example, you can see a comment that clearly states that a result can only get worse in the Jenkins source code
e.g.
462 // result can only get worse
463 if (result==null || r.isWorseThan(result)) {
That being said....
Once the job is done, you can "technically" log on to the master and do whatever you want to already completed builds via changing the build.xmls directly.
For example, you could add a post build job that will go through the files on Jenkins master and do a mass update to replace "<result>UNSTABLE</result>" to "<result>SUCCESS</result>" to turn all builds to success. Once the job is done, forcefully restart the Jenkins server or reload its configuration for the changes to take effect.
I don't recommend this as who knows what will happen to Jenkins if you start going crazy like this. ;)
I am using the Jenkins Delivery Pipeline plugin. I have some parameterized builds that are manually triggered. If I trigger a build from the project page, the build shows a screen where parameters need to be defined (as expected). However, when I start a parameterized build from the Delivery Pipeline plugin, it just starts the build without offering a screen. This is strange behavior, is it possible to get the pipeline plugin to show the parameterized build screen?
Thanks for your help!
I'm answering this question in general.
You need to use the Parameterized Trigger Plugin, or use the Build Pipeline Plugin. This issue with Delivery Pipeline plugin is still being solved by the Jenkins Team. See this link for the update about the issue at https://issues.jenkins-ci.org/browse/JENKINS-25685. You can get to know when it gets resolved from that link.
You can use the Build Pipeline plugin if it can be incorporated in your use case. There was a similar issue for the Build Pipeline plugin which is fixed now. It got fixed within 22 days (https://issues.jenkins-ci.org/browse/JENKINS-25427, https://github.com/jenkinsci/build-pipeline-plugin/pull/56). You can just hope that the same issue with the Delivery Pipeline plugin is fixed soon.
Can you provide me the version of Jenkins, environment and the plugin version? I can update my answer based on the answers you give.
When you are using the Delivery Pipeline plugin, and you have manually-triggered parameterized builds, as long as you configure the upstream job to pass along the parameters to the downstream job, when the "build trigger button" is clicked on the pipeline view page, the parameters are automatically passed along.
For instance, let's say you have a setup like this:
Compile_Project ---> Deploy_Project
Let's assume that you are passing a variable called versionNumber from the Compile_Project to the Deploy_Project jobs. Let's also assume that you're using Subversion for your SCM, and your versionNumber looks like 1.0.${SVN_REVISION}. ${SVN_REVISION} is automatically provided by Jenkins, so your version number will look something like 1.0.1234, where 1234 is the commit number provided by Subversion.
On your Delivery Pipeline view, let's say that it's configured to show 3 pipeline instances, and that manual triggers are enabled in the view settings. Your pipeline view page might look something like this (yay ASCII art!):
Compile_Project ---> Deploy_Project (>)
Compile_Project ---> Deploy_Project (>)
Compile_Project ---> Deploy_Project (>)
In this case, I'm using (>) to represent the manual trigger button. The button on the bottom would attempt to deploy version 1.0.1234, the middle button would attempt to deploy version 1.0.1235, and the top button would attempt to deploy version 1.0.1236, assuming your project has gotten consecutive SVN commits.
In order to pass the parameter from the Compile_Project to the Deploy_Project job, you need to do the following. (Note: it sounds like you've already done this part, but I'm including it just in case you might have missed a step, and also for the sake of completeness.)
In the Compile_Project job's configuration, as a Post-Build Action, choose "Build other projects (manual step)". In the "Downstream project names" box, enter Deploy_Project, and then from the "Add Parameters" drop-down, select "Predefined Parameters". In the "Parameters" text area that appears, create a parameter to pass along, which I'll call VERSION_NUMBER. What you'll enter in the text area is then VERSION_NUMBER=1.0.${SVN_REVISION}. This will enable the parameter to get passed from the Compile_Project to the Deploy_Project. However, you're not quite done yet.
In the Deploy_Project job's configuration, you need to set it up to accept the parameter you're passing into the job. To do so, configure the Deploy_Project, and check the "This build is parameterized" checkbox. Then add a String parameter from the "Add parameter" drop-down. In the "Name" field, enter VERSION_NUMBER. At this point, you can then use ${VERSION_NUMBER} in the Deploy_Project's configuration wherever you need in order to specify the correct version number of the project to deploy.