I have a Github project with a webhook to trigger the build on Jenkins.
It works pretty well. I used the option "Trigger builds remotely" from Jenkins.
In the final steps of the build, it updates some files to update the package version, and submit it back to github.
This triggers a new build, generating an infinity loop of builds.
How to prevent this extra build to be triggered?
I tried the option "Polling ignores commits from certain users" to prevent builds from the bot user. but it seems to work only with the Polling process, and not the remote trigger.
Related
We have recently moved to GitHub. But we are facing issue as,
whenever any user is making any commit to the file it is automatically triggering build in Jenkins.
Now the issue is, If more that one developer is working on same project and they are making the commit. so for every commit, Jenkins build is being triggered.
How can we stop this automatic build in Jenkins whenever commit is made?
If you have enabled Github webhook, disabled it.
or
if you have Poll SCM Turn ON disabled it on the Jenkins Job
All my Jenkins jobs are triggered both by a Github webhook, but also via a scheduled build one per week. The build process is heavily cached to make the webhook CI builds finish quickly.
I would like to add a line to my build script which wipes the cache during the weekly scheduled build, and make it build from scratch. Is there a variable in the build script to identify if a build was triggered by a webhook or schedule?
Maybe the envInject plugin will give you what you need?
This plugin also exposes the cause of the current build as an
environment variable. A build can be triggered by multiple causes at
the same time e.g. an SCM Change could have occurred at the same time
as a user triggers the build manually.
The build cause is exposed as a comma separated list:
BUILD_CAUSE=USERIDCAUSE, SCMTRIGGER, UPSTREAMTRIGGER, MANUALTRIGGER
In addition, each cause is exposed as a single envvariable too:
BUILD_CAUSE_USERIDCAUSE=true
BUILD_CAUSE_SCMTRIGGER=true
BUILD_CAUSE_UPSTREAMTRIGGER=true
BUILD_CAUSE_MANUALTRIGGER=true
I'm trying to configure an automated pull-request job triggering in a monorepo concluded from several subdirectories. This means I need to run a specific pipeline per subdirectory, and not run unnecessary ones.
What I have already tried:
Github Pull Request Builder plugin - Which is a great plugin for those who are not running a scripted pipeline, but rather a "Classic" Jenkins project. Also, it is no longer supported and many issues remain unanswered there.
Git SCM Jenkins Plugin - which has a promising feature of includedRegions and excludedRegions, and is supposed to trigger jobs based on a regular expression. Unfortunately, it doesn't work as expected and triggers builds on any changes.
Using the Git changeset that Jenkins receives, perform a Validate stage when build starts, and if none of the changed files starts with the required subdirectory - abort and exit the build. This results in tens of aborted unnecessary builds.
Jenkins Generic Webhook Plugin - This plugin is a simple to use plugin that relies on the json payload it receives in a webhook, and triggers a job based on a defined filter. The problem is that in Github's API, pull request opened/updated events do not include the changed files. So this use case only works with Github's "push" event, but not specifically with PR events.
I want the flow to work this way:
A developer opens a pull request in Github. His/hers changes are related to a subdirectory in a monorepo called APP1/.
Jenkins receives a notification (or a webhook of some sort) and triggers a job that builds and tests APP1.
Jenkins sends the build/test result back to the pull request checks view (I've got this stage covered).
I inherited a project set up to use Jenkins. I set the trigger to poll SCM every 5 minutes and disabled the pre-existing build remotely trigger. So now the only trigger set for Jenkins is to poll SCM every 5 minutes. However jenkins is building the project everytime the project repo is updated and NOT on polling. The polling log specifically says that it won't build (due to the author of the commit being in the excluded list) but the project builds anyway, unrelated to the polling. There are no other triggers set.
I didn't find any scripts anywhere that could explain this behaviour.
We're using Jenkins with the Gerrit Trigger plugin so when a changeset is uploaded to Gerrit for review, Jenkins will check if it compiles and post the results.
The workflow happens like this:
A changeset is uploaded to Gerrit
A gerrit hook notifies Jenkins of the new changeset, giving Jenkins certain information such as the Gerrit changeset ID, patch number, target branch, etc.
Jenkins launches a build in the project that is configured to listen to this repository.
When the project is finished building, jenkins reports the result back to Gerrit if the build was successful or not, either +1 or -1. This information is used by the code reviewers in gerrit to help them decide to accept the changeset or not.
Problem: When these builds fail, the Jenkins project is marked "Failing" or "Unstable". This isn't exactly accurate, because the changes that caused the failure are not accepted or merged into the repository yet, they are just newly proposed.
One feature of Jenkins is that it will measure the health of a project based on the ratio of successful to failed builds. If the builds are all working, it will show a "sunshine" symbol but if some are failing then you get a "thundercloud". How do I configure Jenkins so that these verification builds don't affect the stability rating of the project? We need the status for the project to show "sunshine" if the commits that are approved from Gerrit and merged into the git repository builds, regardless of the outcome of builds from changes that are not merged (those changes in Gerrit still pending review). It's ok for the individual build to be red instead of green.
At $DAYJOB, we handle this by using 2 separate build jobs. A commit validation job, which posts +1/-1 on Gerrit changes and which we don't care about build stability. And a build stability/regression job, which runs builds that have already been merged where we do care about stability. We ignore the status color for the commit validation job.
I'm not aware of any way to get the Jenkins plugin to give a -1/+1 vote but always show a status of green. It uses that status when determining what score to give.