In a regular free style job, I would like to set the build status on every GitHub commit (pending, success, & failure). This is really easy to do with the GitHub plugin. The only catch is that I want to change the context being sent to GitHub. By default, the plugin sends the full project name ('/folder/subfolder/job-name-foo') or the display name if configured in the advanced project properties.
I want the context to be 'continuous-integration/unit-tests' for my unit test jobs and 'continous-integration/style-checks' for the style check jobs. I can't change the display name in all of my jobs to those values because I would have a ton of conflicts. I have several hundred jobs.
I've found a merged PR that adds the functionality to set a custom context, but I can't figure out how to use it!! https://github.com/jenkinsci/github-plugin/pull/100
It uses the token macro plugin which I've never had to explicitly use https://wiki.jenkins-ci.org/display/JENKINS/Token+Macro+Plugin but I understand how to use it. The problem is that I can't find the right token to overwrite the GitHub context.
So far I've tried:
${displayName='Foo'}
${displayName,foo}
${displayName,var=foo}
foo
I've tried about a dozen or more combinations. Anyone else set a custom context?
This plugin provides a build step to set commit status with different contexts: https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Integration+Plugin
You can invoke this step with different commit contexts at different stages of build.
Related
I am switching from the github pull request builder plugin (for security reasons) and am trying to get the same functionality from Pipelines (using different plugin). I think I have just about everything, however I can't seem to find a way to re-trigger a build simply by a trigger phrase like in github pull request builder plugin. Is that possible via pipelines?
By trigger phrase, I mean that a user can make a comment on the PR saying "Jenkins re-test" and it will kick off the build again.
You can put a condition at the top of the build script to check for the message. You can access the changesets using currentBuild.ChangeSets. The last changeset is at the end of the array. Then you need to access the last element of that changeset. Finally you can access the message via message property. You can then search for your keyword.
I am doing the opposite (not triggering the build with a phrase) but never tried for pullrequests though.
Another idea is to use the "ignore builds with specific message" property and setting this message to be a regex with look ahead that accepts everything except the keyword. I don't really recall the syntax though :/
I did a little search and googling for this issue, but most of the posts are related on how to isolate (by using git plugin etc.)
What I'm wondering is there a way to configure a jenkins job to trigger a build on specific commit message (let's say if it contains "build") on the branch I specified.
Thanks in advance,
You can use Commit Message Trigger Plugin to achieve this.
Once you install this plugin, go to your job configuration page and under Build Environment section check Enable Commit Message Trigger,then add the keyword that will cause the job to trigger.
The answers by #ANIL is totally correct just a few improvement to make thinks clear.
if you put the keyword as admin as shown in image then in your commit message you must
have "ci admin" included and it works. It didn't work without adding ci ahead of keywords in my commit message for me.
We don't have to add ci in keywords in the build environment setting.
I wonder, if it is possible to create generic parametric jobs ready to copy where the only post copy action is to redefine its parameters.
During my investigation I find out that:
- I can use parameters in svn path definition
- I can define the flow of builds using *Build Flow Plugin*
However I cannot force Jenkins to use parameters inside job names definition for promotion process. Is any way to achieve that?
Since I create sometimes branches from master I would like to copy the whole configuration of jobs but only one difference most times is that in the job name definition I replace master with branch name.
Why it not possible to use a parameter as the branch name?
Then when you start to build the job, you can input the parameters based on the branch you want to build.
Or find some way to get the branch info and inject it.
For example, we have one common job, which will monitor maybe 20 projects, if any of those job was merged into git, our gerrit trigger plugin will start to work, and all of job name, and branch is got dynamically from parameters.
Hope this works for you.
I am using Jenkins in combination with the Git and Gerrit plugins. I would like to trigger a job on Ref Updated. However, I need to understand if the action behind this event is the creation of a new branch. If it is, then I will execute my shell script, otherwise not.
As far as I understood, this info is available in the Gerrit's event json response, but I do not know how to consume this json object via Jenkins in the first place.
Is there a way to achieve this easily via Jenkins (maybe something in the interface I missed)? Or is there another way to monitor the creation of a new branch while still in the Jenkins/Gerrit plugin environment?
So I just recalled there are a bunch of Gerrit environmental variables which are available to use in the building script,
namely these ones. I will just have to check if GERRIT_OLDREV is equal to 0000000000000000000000000000000000000000 and if so, it would mean the branch is newly created (for reference: here). Here is the picture I attached in full size.
Is there a way to restrict a build step for a user. I have added a build step using the templates plugin, this template is for the deployment.
I do not want any users who has access to create a job or modify a job to be able to use this build step. The new build step that has been added should only be used by the the administrator.
If people can modifying Job configuration, they can get around any limitation you would place.
If your step can be executed post-build, I suggest to take a look at Promoted Builds plugin. The promotions can be configured to be limited to certain users only. But again, if a user has ability to change job configuration, they can overcome that easily.
The only way I can think of, is to have an external script (or preferably a compiled program than cannot be simply "read" with text editor) that is expecting a password that only you now, before executing whatever secret stuff that you want.