Since I'm using Gitflow all my branches include a slash. Like "feature/awesome-feature".
When I try to tell Jenkins to build this branch it throws an error "ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job."
Is it possible to use "/" in branch names at all? The issue was reported/fixed/unfixed numerous times. So I'm not sure about the current state.
Yes I build branches like this all the time and it works just fine.
Set your branch as "refs/heads/feature/awesome-feature"
Which version of jenkins are you on?
I'm on 1.580.3
Do you have any commits yet? If your repo is empty, it would have no HEAD, and therefore no branch, as in this question: While building a git project from jenkins it shows an error like couldn't find any revision to build
Related
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 a Jenkins system. It runs build jobs for our company. We run multibranch pipelines. Yesterday one of the builds mysteriously dropped the devel branch from the build.
I looked through the Pull Requests for the branch and I can not find anything that affected by the Jenkins file in the time frame where this branch drop occurred.
I have looked through the Jenkins system log and I do not see any errors. Here is a copy of the relevant parts of the scan repository log:
Examining Bo**a/pro-***-ter
Checking branches...
Getting remote branches...
Checking branch devel
Getting remote pull requests...
Checking branch master
‘Jenkinsfile’ found
Met criteria
I have validated that the devel branch has a Jenkinsfile and that the Jenkinsfile is valid.
I can't figure out how to solve this. Any suggestions would be great.
Some plugin information:
github 1.28.0
branch 2.0.11
docker-common 1.13
docker-pipeline 1.17
git 3.6.0
git client 2.7.0
git server 1.7
SCM API 2.2.3
Jenkins version 2.73.2
I had this same problem with BitBucket Server and Jenkins when using Blue Ocean (BitBucket Server plugins). The branch would not create in Jenkins. I noticed that the branch commit and the pull request (PR) had a successful build. It seems that if Jenkins detects a PR is opened for a branch, it will not create the branch on the Jenkins side. Once I deleted the pull request from BitBucket Server, Jenkins registered the branch and it showed up. Would be better if the branch showed up, had no builds and referenced the Pull request Jenkins job!
Sorry for taking so long to answer this:
I did a plugin upgrade to the latest version of all of the plugins in my Jenkins.
That solved my issue.
I think we might found an answer (or problem causer).
In our case we automatically restarted Jenkins once a day in either in the shut down or boot up process branches went missing.
The amount of missing branches declined significantly after keeping the Jenkins running all the time.
Detected unsupported subitem repo » develop, skipping
In my case I just deleted the develop pipeline(by clicking its link on scan branch log page) and rescan, all worked.
It seems while performing scan it probably point to an obsolete hash in Git preventing Jenkins job to scan correctly.
I am using the "inverse" build strategy. When we do a merge from feature branch to development branch, then from development branch to release branch. We can see Jenkins did see the changes in the branch, but started only one build. It's not starting the build for origin/REL-Sprint1606. There is line shows Label=[origin/REL-Sprint1606]
Checking out Revision b81dd73053889e753b41565a4ecec99c081eb1b0 (origin/development, origin/REL-Sprint1606)
Regular expression run condition: Expression=[.*\/[dD][eE][vV].*], Label=[origin/development ]
I found this bug report to Jenkins, but it's closed now:
Git plugin only triggers a build for one branch
https://issues.jenkins-ci.org/browse/JENKINS-11337
In Jenkins, I have a "Build" job setup to poll my git repo and automatically build on change. Then, I have separate "Deploy to DEV", "Deploy to QA", etc. jobs that will call an Ant build that deploys appropriately. Currently, this configuration works great.
However, this process favors deploying the latest build on the latest development branch. I use the Copy Artifact plugin to allow the user to choose which build to deploy. Also, the Ant scripts for build/deploy are part of the repo and are subject to change. This means it's possible the artifact could be incompatible between versions. So, it's ideal that I ensure that the build and deploy jobs are run using the same git checkout.
Is there an easier way? It ought to be possible for the Deploy job to obtain the git checkout hash used from the selected build and checkout. However, I don't see any options or plugins that do this.
Any ideas on how to simplify this configuration?
You can use Parameterized Trigger Plugin to do this for you. The straight way is to prepare file with parameters as a build step and pass this parameters to the downstream job using the plugin. You can pass git revision as a parameter for example or other settings.
The details would vary for a Git repo (see https://stackoverflow.com/a/13117975/466874), but for our SVN-based jobs, what we do is have the build job (re)create an SVN tag (with a static name like "LatestSuccessfulBuild") at successful completion, and then we configure the deployment jobs to use that tag as their repo URL rather than the trunk location. This ensures that deployments are always of whatever revision was successfully built by the build job (meaning all unit tests passed, etc.) rather than allowing newer trunk commits to sneak into the deployment build.