| Multibranch pipeline is unable to checkout branches discovered by 'Discover other refs' Jenkins ver 2.176.1. To reproduce the problem: (1) create multibranch pipeline with 1 Behaviour Discover other refs. Refs should be located OUTSIDE of refs/heads (in my example it was refs/merge-requests//merge*) so no default git mapping <branch_name> -> refs/heads/<branch_name> could be used implicitly (2) run branch discovery, job for specific branch would be run with result:
Branch indexing
> git rev-parse --is-inside-work-tree # timeout=10
Setting origin to
XXXXXXXX
> git config remote.origin.url
XXXXXXXX
- timeout=10
Fetching origin...
Fetching upstream changes from origin
> git --version # timeout=10
> git config --get remote.origin.url # timeout=10
> git fetch --tags --force --progress origin +refs/merge-requests//merge:refs/remotes/origin/merge-requests//merge
> git rev-parse refs/merge-requests/1/merge^{commit} # timeout=10
ERROR: Could not determine exact tip revision of merge-request-1; falling back to nondeterministic checkout
Then Jenkins tried to get commit 2 more times but the result is the same. The culprit is the false assumption in git rev-parse refs/merge-requests/1/merge^{commit} invocation that the selected branch would be available directly under refs/* which is not true and even refspec used during fetch confirms that. git rev-parse should be run on local remote tracking branch ref refs/remotes/origin/merge-requests/1/merge, not its server counterpart refs/merge-requests/1/merge. There is a quick workaround for this: create Specify ref specs which would mirror server branch to client branch 1-to-1, in my example '+refs/merge-requests//merge:*refs/merge-requests//merge'.*** Additionally (this is not directly related to the problem above) reading Jenkinsfile stage could be optimized by passing --depth 1 switch to git fetch (only during Jenkinsfile discovery!). We don't have to fech full branch history to be able to read Jenkinsfile from the tip of the branch. |
