I am also getting this in various cases. It's more common when an upstream job triggers the pipeline, but it happens on multibranch pipelines that don't get triggered by other jobs too.

I also ran into this issue this week.  I got the same error using a Jenkinsfile in a project that only has the Jenkinsfile in the develop branch currently.  My only recourse was to use command line Git in a shell directive to perform a checkout on the develop branch and then pull.

I just noticed that the issue is in Resolved state.  How was it resolved?  Was there a code fix for it?

I am reopening the issue because I found a way to replicate the issue: this happens when there was a forced push on the git server.

The client needs to be able to detect this and to abort the build probably?

Also, I suspect similar thing may happen if the workspace is not cleanup and there is a forced push on remote git. To prevent a permanent failure of all future jobs we need an option to perform a forced pull when such error occurs — as in a self-repairing local clone.

I also encountered this in my project when building Jervis. Seems like odd behavior. If it can't compare to a previous revision then it should default to the git tip of the branch.

This reliably happens to me. I shut down the service and start it. If I enter a branch and run it (after having already built it once) I get this issue.

I'm using the pipeline multibranch plugin. Anybody can bootstrap my project with vagrant and replicate the behavior. https://github.com/samrocketman/jenkins-bootstrap-jervis

I would like to point out that this plugin is attempting to resolve the tip of my "jervis_simple" branch (as it should because I am building the jervis_simple branch) but for some reason is flailing about with the tip of master branch.

Started by user Sam Gleske
Running in Durability level: MAX_SURVIVABILITY
Loading library Jervis Global Library@master
Attempting to resolve master from remote references...
 > git --version # timeout=10
using GIT_ASKPASS to set credentials GitHub user and personal access token used by multibranch pipeline jobs for the GitHub API
 > git ls-remote -h -t https://github.com/samrocketman/jervis.git # timeout=10
Found match: refs/heads/master revision a82c0668ab31f0c992d26575e415971648c5c185
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/samrocketman/jervis.git # timeout=10
Fetching without tags
Fetching upstream changes from https://github.com/samrocketman/jervis.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials GitHub user and personal access token used by multibranch pipeline jobs for the GitHub API
 > git fetch --no-tags --progress https://github.com/samrocketman/jervis.git +refs/heads/*:refs/remotes/origin/*
Checking out Revision a82c0668ab31f0c992d26575e415971648c5c185 (master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f a82c0668ab31f0c992d26575e415971648c5c185
Commit message: "bump to snapshot"
 > git rev-list --no-walk a82c0668ab31f0c992d26575e415971648c5c185 # timeout=10
[Pipeline] End of Pipeline
ERROR: Could not determine exact tip revision of jervis_simple
Finished: FAILURE

This looks to be the exact situation of the second case I describe in https://issues.jenkins-ci.org/browse/JENKINS-48571?focusedCommentId=329111&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-329111

Namely the Job DSL plugin is being used to configure a branch source that has a null id. You must provide an ID: https://github.com/samrocketman/jervis/blob/b25af324cce229255fd34c9070f32da4d0d8b393/jobs/jenkins_job_multibranch_pipeline.groovy#L38-L52

Change

                    github {
                        //github
                        credentialsId 'github-user-and-token'
                        repoOwner project_folder
                        repository project_name
                        //behaviors not supported by job dsl

                        //additional behaviors
                        traits {
                            headWildcardFilterWithPR {
                                includes "${JERVIS_BRANCH}"
                                excludes ''
                            }
                        }
                    }

to

                    github {
                        //github
                        id 'anything-does-not-matter-as-only-one-source-configured'
                        credentialsId 'github-user-and-token'
                        repoOwner project_folder
                        repository project_name
                        //behaviors not supported by job dsl

                        //additional behaviors
                        traits {
                            headWildcardFilterWithPR {
                                includes "${JERVIS_BRANCH}"
                                excludes ''
                            }
                        }
                    }

And the problem should go away.

sag47 can you confirm the above?

Thanks for the pointer, I will make the change to test.  I'm glad my projects are open source so you are able to inspect it and give me pointers stephenconnolly.  I will report back my results.

stephenconnolly your suggestion appears to have fixed the issue.

Fixed by https://github.com/samrocketman/jervis/commit/e4cd6324ff22c3593d7e6feab88dff79e516e14b

I'll do some more testing but it now appears to work reliably.

Required

After making the change from stephenconnolly's suggestion I had to click "Scan Repository Now".  The problem continued to be broken until I scanned the repository for branches.

Results (the fixed flow)

The following flow is how I reproduced reliably and confirmed the fix.

1. Bootstrapped Jenkins with vagrant
2. Generated a multibranch pipeline for samrocketman/jervis project.
3. Clicked "Scan repository Now" so branches would be detected.
4. Clicked "Build now" on the jervis_simple branch.  This always succeeded the first time.
5. Log into Jenkins and restart it.  /etc/init.d/jenkins stop; /etc/init.d/jenkins start
6. Visit the jervis job and click "Build now" (the ERROR used to occur here every time with this flow; clicking build repeatedly and restarting Jenkins did not help and caused the same failure every time)

After the fix, step 6 above now always works and I no longer encounter the error.  I will test further to be absolutely sure it's fixed.  Thanks Stephen!

great - I might close this as a duplicate, but sag47's comment above is handy! thanks