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.
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 :/
Recently my company has gone with Jenkins as its CI/CD solution, after trying a number of options. I'd like to disable checks from the other CI packages.
I've deleted the SSH key and web hooks from Circle CI, but it still marks the build check as "failed" on the merge requests (it's only partially implemented.)
I'd like there not to be a CircleCI check at all. How do I accomplish that?
From within CircleCI, click unfollow and then remove.
Going to a user|organisation profile Settings, then "Third-party application" can also help to remove Circle-CI.
This approach worked for me:
https://discuss.circleci.com/t/remove-projects-we-accidentally-added/27766
You create a script with your token and group name, then create a file with your repo name in it and run the script with the file as a param.
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.
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.
I am using jenkins for continous integration.
For my build purpose, i triggering email using Ant task. I am not able to find an environment variable to pass ant for sending email build status(success/failure/stable).
i want to know how can i get environment variable for build status?..if not available, what is the alternative option for build status?
Thanks in Advance
varghese
Why use ANT to send emails from Jenkins when you have two great plugins that does just that?
The default mail notification is quite good, and if you would like to have more control
I suggest using the Email-ext plugin which is very comprehensive.
If still wish to use ANT to sent your mail-notifications including the status
you will have to break your process into two steps,
where the first part runs the build and the second one runs the ANT script to report the status.
In this case, you will need to trigger the second job from the first job via the Parameterized Build plugin -
see my answer here:
trigger other configuration and send current build status with Jenkins
The build status is not set until the job has finished running, so there is no easy way to push build status to a process triggered within the build itself. You could pull build status via the API, but this would have to be an externally triggered process due to the constraint mentioned above. Any reason you aren't using the built in email support or one of the excellent email extension plugins such as this one?