Is there a way we can trigger another build manually without pushing another commit into merge request?
I'm using Jenkins and Gitlab integration
https://wiki.jenkins.io/display/JENKINS/GitLab+Plugin
The regex-solution did not work in our setup, perhaps old/missing plugin in jenkins... But yesterday I found the best "solution"/hack (at least for me :-) ) by changing the TARGET branch of the merge request. Then I changed it back to the original one and a new pipeline startet without a senseless commit!
There is an option in the "Configure" page of the Jenkins job for that (a recent addition I think).
Look for the textbox named:
Comment (regex) for triggering a build
Source:
http://blog.ljdelight.com/gitlab-trigger-jenkins-builds-on-merge-request/
Related
Is there any way to make Jenkins builds after each commit in any branch ?
Because i found in my project's configuration that Jenkins run build only after detecting commits in specific branch or in the default ( eq to master in git ).
PS: i'm using mercurial and Jenkins file.
Should i change project type ( new item type in Jenkins ) or are there any modifications in configs.
There are two things that you should check for this (I haven't work with Mercurial)
Does Mercurial has the option to create webhooks?
There is a jenkins plugin for Mercurial? (I think there is)
You must configure on the mercurial site the webhook pointing to Jenkins and give the point to the job you want to run, and on which events does it will fire. On the Jenkins side you must configure on the job who it will behave.
For example, with GitLab, the plugin has an option configured on the "Build Trigger" section where you configure the events and the branches that fires the job. In GitLab, in the repository you create the webhook, that is only a URL pointing to the Jenkins job.
I got this solution and it worked for me.
with Mercurial, we can use the "tip" keyword.The tip revision is the most recent changeset in the repository. It is the most recently changed head.
We have one project configured as multibranch pipeline project with branch filtered master and development. After few hours the master branch is disabled with a strikethrough symbol across its name and build option not available .
When clicked on "Scan Multibranch Pipeline", it enabled the branch and pipeline logs show "Branch ReOpened".
Initially we assumed it would be because of Option "Exclude branches included in pull request" but enabling "All branches" too is disabling the master branch time and time again.
Pipeline Logs are not providing any clear indication of whats happening causing it to disable .Please help .
Old topic but I faced the same error today but the solution was different.
The error was in the configuration of branch discovery
Discover branches > Strategy. I was using Exclude branches that are also filed as PRs
And there was a PR targeting this branch. Change for All branches did the trick.
This looks like a bug to me. First I'll go to http://[jenkins]/log/all to see if there are any interesting logs there, then I would open an issue on https://issues.jenkins.io/secure/Dashboard.jspa
Also this issue might be happening after a recent upgrade of jenkins plugins or jenkins itself, I would downgrade everything to try to get my jenkins back to the way it was, then upgrade the plugins one by one or few by few to try to isolate what is causing the issue.
Finally, if you have jobdsl scripts, I would check these scripts to see if there is not a script that when executed is recreating the job and overrides the disabled status
Not sure if you're using Bitbucket Branch Source plugin for hook on Jenkins, but I had the same issue on 737.vdf9dc06105be version. Everytime I pushed a change to branch (not pull request) it got disabled (strikethrough). Scan multibranch pipeline was restoring it until next push notification on webhook was performed.
Upgrading the plugin to 751.vda_24678a_f781 version resolved the issues:)
I have a Jenkins Multi branch job that checks out and builds code from GitLab.
Until recently it was working without issue but now some (but not all) branches from the good master fail to build.
Master always builds without issue.
When I branch master either from the repo in GitLab or via a git checkout -b locally and push back to Gitlab and then allow the multibranch job to pick up the new branch it fails to build it.
I get the message from the pipeline plugin SCMBinder class: "Could not determine exact tip revision of [branch]; falling back to nondeterministic checkout".
When I do a git status in the workspace on either master or a slave the Head is detached.
When I git clone the code locally and checkout the branch everything is fine and the head is properly attached.
Additionally, when I create a simple pipeline job in Jenkins with the problem branch it builds ok and inspection of the workspace shows the head attached.
I have upgraded Jenkins and the plugins but this has not helped.
The confusing thing is that I have some other branches I created from the same master that builds perfectly fine in the same multibranch pipeline job.
Also if I branch a good branch then I get the same issue in the multibranch pipeline.
Can anyone suggest what is going wrong?
I also faced similar issue for multi branch Jenkins project.
When I clicked the option "Scan Multi branch pipeline now" in the left side menu, the problem got resolved.
Hope it might help some one.
I found the answer to this, so answering it here to help others and stop anyone from wasting their time on it.
Essentially this was caused by linux/windows interoperability issues/differences around the use of case in the branch naming which translates into a folder naming issue because windows does not care about case but GIT does.
Simply put, the first branches I previously created for the problem repo I was using a prefix lets call it "Prefix" with an uppercase "P".
These branches were pulled into a multi-branch pipe and built ok.
Then, I created a branch with the prefix "prefix" with a lower-case "p". This branch failed to build in the multi-branch pipeline.
As we know Windows does not care about case and so does not create a new folder structure in .git for "prefix" as it thinks it has one already called “Prefix”.
The appropriate HEAD and commit information is put under the original file structure under “Prefix”.
GIT however when it tries to checkout the code cannot find the head/commit information for the branch starting "prefix" as it is looking in .git for the commit/head details under "prefix" and not "Prefix" which does not exist hence results in a detached head.
I am going to start enforcing some syntax rules for branch naming in future so that this does not happen again.
I got this problem apparently because of a Jenkins upgrade. I had to (re)create the "Branch Sources" part of the configuration to fix it.
I had the same issue exactly , but with Bitbucket .
For me the issue happened due to a dev/ or Dev/ Prefix being used,
While the only prefixes defines on the Bitbucket side were :
bugfix/
feature/
hotfix/
release/
Tested the same branch with feature/ instead of dev/ worked perfectly ,
Also changing the prefix from feature/ to dev/ in bitbucket worked , but the issue there is that you cant add additional prefixed , only change one of the four already there , so i just ended up enforcing a policy to prevent people from using dev/ or any other abnormal prefixes in their branch names.
I have configured my branch for a Pipelines project like this:
*/master
However, according to the Git poll log:
[poll] Latest remote head revision on refs/heads/ci_test is:
c945253a1f3aed6be113347e37aa3512db43bcf0 - already built by 17 Done.
Took 11 sec No changes
It always tries to poll ci_test that was the branch I initially tested with. Same thing with BitBucket webhook. It reacts only on the ci_test branch despite that fact that only master is now configured, applied and saved. I also tried to restart Jenkins with no luck.
Any ideas how to debug this?
Edit: If I trigger the build manually it builds master. The poller still polls ci_test no matter what. Wtf?
Edit2: Setting the branch to any (leave blank) fails to fetch anything even manually.
The solution that worked for me was:
Delete all configuration related to polling (trigger clause in the pipeline, polling configuration in the job)
Run a build manually (it should build the correct branch)
Restore polling configuration
After these changes, polling restarted and began to query the correct branch.
The "solution" was to move on to a Multibranch Pipelines project. The legacy Pipelines project seems to be confusing and broken with multiple branches anyway:
https://issues.jenkins-ci.org/browse/JENKINS-46588
Additionally the webhook might also be somehow buggy, but this multi-branch project type seems to be working much better.
For me the issue was that I had specified "Branch Specifier" as */* and changing that to empty value fixed the problem, as instructed: (blank for 'any').
Probably for you case you should put 'master' instead of */master
Seems to be that the problem is with webhook on BitBucket, not with Jenkins configuration. Probably webhook was created for ci_test branch and now doesn't see the changes for master branch.
I have this issue (our Jenkins server hasn't been updated for a couple of years, so pretend the date on this post is 2017). I believe it's because of this bug (I believe both are the same problem):
https://issues.jenkins-ci.org/browse/JENKINS-50168
https://issues.jenkins-ci.org/browse/JENKINS-55524
I don't have a solution, although I'll update this answer if the multi-branch pipeline works.
Be sure that you don't have enabled the Lightweight checkout checkbox in the Pipeline section.
Unfortunately, it's not compatible to Bitbucket webhook plugin..
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>]