Every time patchset-created event triggered, zuul clone the whole repository.
how to stop this? because it takes a too long time and makes job starts very slowly.
This is not the expected way Git plugin works. Go to the job configuration > Source Code Management > Git > Additional Behaviours, and see if the "Wipe out repository & force clone" option is set like in the following example:
Related
I think I've done the hard part already: the Github webhook after a push always returns a success message.
I can build manually. But it never builds after the push, because "polling" never happens.
Both the GitHub Hook Log and Git Polling Log say "Polling has not yet run".
Here is my configuration:
Branches to build: refs/heads/checkJenkins
Build Triggers: GitHub hook trigger for GITScm polling, Poll SCM
Build: Execute shell: 'git pull'
Any ideas on how to get the polling started?
A side question: which should be doing the polling when I'm using the webhook in github: the "GITScm polling" or "Poll SCM"? Can I delete one of those settings?
Poll SCM is to scan the repository for changes at regular intervals as specified by the cron under Schedule. So this option is redundant.
Now coming to the hook, is it configured to deliver everything or just the push event? You can hit http://<jenkins_url>/log/all in your browser to see the system log while pushing changes. Towards the bottom of this log, see if Jenkins has received the hook and poked the job. If the hook is not received, reconfigure it at GitHub to send the appropriate events. Else, delete and recreate the job as sometimes Jenkins fails to register a new job to poke on receiving events and at other times a new job itself doesn’t respond to poking.
It's enough to keep only GitHub hook trigger for GITScm polling on, because this is the right option for conditional triggers (following git push as opposed to scheduled as a cron job, i.e. proper polling 1).
As for ideas on how to get the triggering (not polling) started, consult my "pre-flight checklist" here, because it's not a trivial matter.
Side note: feel free to report it to the Jenkins Github Plugin devs if you also think that the word "polling" is misplaced in this option (as per the definition of this term).
I try to configure Jenkins. I want a simple behavior: trigger a build on new pull request.
I cannot understand what I missed...
Jenkins version: 2.89.2
At https://ci.mysite.fr/configure :
Still no build triggered:
At https://ci.mysite.fr/job/test-back/configure :
On Github, Webhook is sent and well received by Jenkins:
Nginx Log says the same:
Help please!
Some things to check when debugging this sort of thing:
Check your Jenkins logs to see whether or not Jenkins is receiving the hook and deciding not to take action for some reason.
Check Jenkins security by clicking Manage Jenkins -> Configure Global Security. Open things up as much as you're comfortable doing and see if that changes anything.
Ensure that you're pushing changes to the master branch. For simplification, consider using ** as your branch specifier while you're getting this to work.
Ensure Git is properly configured on your Jenkins host by clicking Manage Jenkins -> Global Tool Configuration
Make sure the user whose credentials you provided can manage hooks and pull from the repo you're interested in.
Run the job manually in Jenkins, ensure that it works.
After you run the job, it should show up as an option in Protected Branches/Required Statuses. In your repo, click on Settings->Branches, select your branch in the Branches section, click Require Status Check to Pass before merging option, and your job should show up in the list which appears.
Webhooks are arguably the most difficult Jenkins feature to test without prior experience, because of gotchas like these (probably their list is incomplete):
New git commit / git push must be made for each pipeline build (repeating a previous one won't trigger a new build even if webhooks are already set up correctly - see below).
First build made after setting up webhook correctly must be manual (no bootstrap from the webhook itself is possible).
First build made after setting webhook correctly must succeed completely for the changes to take effect and for webhooks to start working. This will also cause Jenkins to miss all incoming requests made during the first build of a newly created pipeline.
More info
Please be warned that it is not possible to trigger a build using the same build conditions again (at least using a webhook). Therefore you might have a correct webhook setup already, but not find out that it works unless you create a new git commit and push it to the remote repo on Github. If your try to repeat some old push over and over again, by simply pressing the "Redeliver" button in the Recent deliveries section on Github's Webhooks / Manage webhook page, Jenkins will never move beyond the "poke" repo stage, as it requires SCM changes to be detected in order to trigger a new build:
Received PushEvent for https://github.com/mirekphd/<REPO_NAME> from <GITHUB_IP> ⇒ <JENKINS_URL>/github-webhook/
Apr 16, 2021 9:42:12 PM INFO org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run
Poked <REPO_NAME>
Apr 16, 2021 9:42:13 PM INFO com.cloudbees.jenkins.GitHubPushTrigger$1 run
SCM changes detected in <REPO_NAME>. Triggering #236
For further info on points 2) and 3): see original source.
I recently made the transition from Subversion to Git for all my repos at work. However, with svn we had commit hooks in place so that our Jenkins job would run for whichever branch was checked into. Now, I'm trying to set this up using Gitlab and there appears to only be one place to add a web hook. It looks like any time something is checked into ANY branch, the web hook will run. Meaning if I have a branch_A associated with jenkins_job_A, something could be checked into branch_B and the commit hook for jenkins_job_A will still run. Is there a branch by branch way to configure these web hooks? Or is there some kind of script I can check into each branch that will act as a commit hook? Or (my fear) is this feature not supported in Gitlab?
I guess you set up GitLab to do a post commit request to http://yourserver/jenkins/git/notifyCommit?url=<URL of the Git repository>? In theory this should trigger the polling on all jobs that are configured with that URL, and in the polling step the jobs should decide whether they should build or not. In practice this will unfortunately cause all jobs to fire.
We worked around this issue by moving the Job configuration into a Jenkinsfile and then use a Multibranch Pipeline.
As an alternative you could also install the GitLab plugin for Jenkins and use the Jenkins integration in GitLab. This will allow you to trigger the correct jobs when commits are pushed on a branch. The downside is that it requires a per-job configuration.
I'm trying to add some very basic functionality that exists in every other modern ci product, but which unfortunately seems to be a completely foreign concept in Jenkins land.
I have the github plugin hooked up, and the git plugin set to build the "inverse" of "origin/master", so that pushing any branch except master triggers a build.
The problem is, if there's a flaky test and the build fails there's no way to restart it in jenkins. I added the Naginator plugin but it rebuilds the last branch that ran, not the branch of the build that you clicked "retry" on. Using the Naginator plugin, it seems that I need the git branch or sha to be a real parameter of the build. But, I can't find a way to set the git branch as a parameter of the build when a build gets triggered.
The only thing I can think of is to split it into two builds that link to the same git repo, and have the second one be a parameterized build that the first one triggers with the GIT_COMMIT value as the parameter. Then, retrying the second one with Naginator should retry it on the same SHA. This isn't a good solution though, it sucks to have to configure 2 builds for every one of my builds.
Does anyone know of a good way to accomplish this? I'm hoping I'm just missing something simple.
Unfortunately i'm unfamiliar with this exact setup, however the Git plugin documentation, section Push notification from repository, mentions that in the trigger url, the <commit ID is optional. If set, it will trigger a build immediately, without polling for changes.
If there is a built-in "button" in some plugin to issue this manually from inside jenkins UI i don't know, if not that could be a nice feature request.
So, if there really is no easy option aviable yet, as a workaround you could write yourself some script which builds and calls the url for a given branch + commit ID.
Trigger url format, as found in Git Plugin docs:
curl http://yourserver/git/notifyCommit?url=<URL of the Git repository>&branches=branch1[,branch2]*][&sha1=<commit ID>]
To give some context the question is about GitLab and Jenkins setup.
I know how to setup a web hook, I know how to setup a job to be triggered by the hook. The problem is that I need to have multiple jobs and only a single entry-point (parent job) trigger for them.
The downstream jobs at the same time need to be git repo aware so I have to set repo url for them. This causes them to be triggered independently by the hook and I don't want that as this means that they are triggered twice.
On the other hand if I don't configure repo url on a downstream job and the parent job triggers it, it fails as it is not able to do a checkout.
I may try to hack around with some 'execute shell' build step, I believe it's not a valid way to go. Has anybody a good tip how to solve that?
For the reference here is the GitLab Jenkins plugin documentation according to which:
Plugin will parse the GitLab payload and extract the branch for which
the commit is being pushed and changes made. It will then scan all Git
projects in Jenkins and start the build for those that:
match url of the GitLab repo
match the configured refspec pattern if any
and match committed GitLab branch
I tried playing around with different settings, without a great result though.
For the project you want to get only local triggers, just enable Don't trigger a built on commit notification in the Additional behaviours of git plugin.
(https://github.com/elvanja/jenkins-gitlab-hook-plugin/issues/11#issuecomment-35385032, as you actually have discovered).
But a better solution could be to make your downstream jobs reference the repository locally cloned by main job (not sure if actually possible), so the plugin will never consider them for schedule a build, as the git url don't match.