I'm defining my checkout step in multibranch pipeline. During the PR discovery, the BRANCH_NAME is getting the value as the PR number like origin/PR-1 , It is searching for a branch with the name "origin/PR-1", which obviously it doesn't find and fails with error revision not found. But this works for the branches not created as PR.
My Github Branch discovery strategy is: "Exclude branches that are also filed as PRs"
My Github PR discovery strategy is: "Merging the pull request with the current target branch revision"
Can someone help with the fix which works for both PR discovery and branch discovery
checkout poll: false,
scm: [$class: 'GitSCM',
branches: [
[name: "${env.BRANCH_NAME}"]
],
extensions: [
[$class: 'GitLFSPull'],
[$class: 'CleanCheckout'],
[$class: 'CleanBeforeCheckout']
],
userRemoteConfigs: [
[credentialsId: 'github_ssh_key',
url: 'git#github.com:engineering/monitoring.git']
]
]
Related
In Jenkins, I have a multibranch pipeline job using a Jenkinsfile. I have disabled the default SCM checkout via:
options {skipDefaultCheckout(true)}
so that I can control the checkout for each stage and use the SSH URL from GitHub. I have a working stage that checks out the "main" branch using:
checkout([
$class: 'GitSCM',
branches: [[name: '*/main']],
extensions: [[$class: 'LocalBranch', localBranch: 'main']],
userRemoteConfigs: [[credentialsId: 'XXX', url: 'git#github.com:XXX.git']]
])
For another stage, I would like to checkout and build/test the branch that is triggered (in this case a feature branch called "feature-0001"). I have tried this (note the change for the branches and extensions lines):
checkout([
$class: 'GitSCM',
branches: [[name: env.BRANCH_NAME]],
extensions: [[$class: 'LocalBranch']],
userRemoteConfigs: [[credentialsId: XXX, url: 'git#github.com:XXX.git']]
])
but I get the following error:
Error when executing failure post condition:
java.io.IOException: Cannot retrieve Git metadata for the build
In addition, the build log also has:
git rev-parse "origin/feature-0001^{commit}" # timeout=10
git rev-parse "feature-0001^{commit}" # timeout=10
I'm not sure where the "^{commit}" comes from or if it's causing any issues.
Any guidance would be appreciated, thank you!
P.S. I have also tried many variations of BRANCH_NAME including
$env.BRANCH_NAME, ${env.BRANCH_NAME}, $BRANCH_NAME, ${BRANCH_NAME}
branches: [[name: "refs/heads/${env.BRANCH_NAME}"]] worked.
I was also using the incorrect url/credentials causing further issues.
If you want an unambiguous way to reference your branch name in the SCM checkout step, try (as explained here):
branches: [[name: 'refs/heads/${env.BRANCH_NAME}']]
The ^{commit} revision specification would therefore apply to the ref refs/heads/${env.BRANCH_NAME}
<rev>^{<type>}, e.g. v0.99.8^{commit}
A suffix ^ followed by an object type name enclosed in brace pair means dereference the object at <rev> recursively until an object of type <type> is found or the object cannot be dereferenced anymore (in which case, barf).
For example, if <rev> is a commit-ish, <rev>^{commit} describes the corresponding commit object.
Background: I am using Git LFS with the repo, and we need to do a Git LFS pull in the checkout logic while using Jenkins's groovy functions for the Pipeline. What this does is replaces the pointers with the actual files which are later on used during the CI compute phase.
Problem: GitLFSPull SCM plugin exists and works without error when used as a scmExtension but it is not giving the expected results, basically the plugin activates, states the below, but I suspect the git lfs pull origin is not working
Enabling Git LFS pull
> git rev-parse refs/remotes/origin/feature/xyz^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/feature/xyz^{commit} # timeout=10
> git config core.sparsecheckout # timeout=10
> git checkout -f hash # timeout=10
> git config --get remote.origin.url # timeout=10
> git lfs pull origin # timeout=10
I would like to understand, am I missing something to use the Jenkins plugin correctly ? The below is the Checkout function that we are using
def checkoutSourceCode(checkoutDir) {
dir(checkoutDir) {
checkout changelog: true,
poll: true,
scm: [$class: 'GitSCM',
branches: [[name: "origin/" + params.SOURCE_BRANCH]],
doGenerateSubmoduleConfigurations: false,
extensions : [
[$class: 'CloneOption', noTags: true, reference: '', shallow: false],
[$class: 'CleanBeforeCheckout'],
[$class: 'PruneStaleBranch'],
[$class: 'AuthorInChangelog'],
[$class: 'GitLFSPull']
[$class: 'UserIdentity', email: 'xyz#gmail.com', name: 'xyzzy'],
[$class: 'SubmoduleOption',
disableSubmodules : false,
parentCredentials : true,
recursiveSubmodules: true,
reference : '',
trackingSubmodules : false]],
submoduleCfg : [],
userRemoteConfigs : [[name : 'origin',
credentialsId: 'xyzzy',
url : 'ssh://xyz.xyn.com/something.git']]]
gitCommit = sh(returnStdout: true, script: 'git rev-parse HEAD').trim()
shortCommit = gitCommit.take(6)
return shortCommit
}
}
So this is how this issue was solved. For my sake and tracking sake.
brew install git-lfs
I had to add the Symlink for LFS ($whereis git-lfs) with that of the system usr\bin\<> so that the master system where the CI runs knows where LFS is, the master system was not finding where LFS is.
Then finally check git lfs status as a CLI command to make sure LFS is there, in the groovy script using sh
I see an issue that it looks like you worked around the problem. But I see a small issue in your Jenkinsfile it looks like you are missing a comma.
[$class: 'GitLFSPull'], <-- here
[$class: 'UserIdentity', email: 'xyz#gmail.com', name: 'xyzzy'],
Is it possible to use parameters to allow users to pass a git sha to a multi branch pipeline while defaulting to the head of the branch? Also I would only need to this function for the master branch.
I'm using ...
Jenkinsfile in code
Jenkins Declarative Pipeline
I was able to do this with declarative pipelines with the following...
pipeline {
options {
skipDefaultCheckout()
}
...
steps {
script {
if (GIT_REVISION=='HEAD') {
checkout scm
} else {
checkout([$class: 'GitSCM',
branches: [[name: "${params.GIT_REVISION}"]],
doGenerateSubmoduleConfigurations: false,
extensions: [],
submoduleCfg: [],
userRemoteConfigs: [[credentialsId: 'XXXXXXX', url: 'git#github.com:xxxxx/xxxxx.git']]
])
}
...
}
}
}
Yes, this is possible, but I guess you have to use scripted pipelines instead of declarative ones.
If the current branch is the master, you configure a parameter for this build (as this isn't super intuitive, I wrote a blog article a while ago). params.INPUT_REVISION for example would then store the given revision and you can set default to HEAD or fallback to it, if the parameter is not yet specified (e.g. for the first run).
You supply this revision to the checkout(scm) step as a parameter so that it doesn't checkout the current master branch, but the specified revision.
How do we achieve Git Additional Behavior in Jenkins pipeline?
Additional Behaviors
=> checkout to specific local branch
check this one http://your-Jenkins:8080/pipeline-syntax/ , you can have samples of all your installed plugins.
checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'RelativeTargetDirectory', relativeTargetDir: 'your-sub-directory']], gitTool: 'Default', submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'd767bb7a-4c1e-4654-a310-996d4ece5b02', url: 'git#github.com:yyy/xxx.git']]])
you can find the pipeline syntax in your Jenkins job slide bar Pipeline Syntax section.
1、Sample Step select checkout: Check out from version control
2、click Additional Behaviours Add button
3、select checkout to specific local branch
4、click bottom Generate Pipeline Script button，you will get pipeline script.
Trying to setup a pipeline for .NET web application and the checkout scm creates a directory name (appname_string). this directory name is more than 248 characters and this is causing the Build step to fail (Directory name should be less than 248 characters). Is there anyway to just have the application name as folder name in checkout step instead of appending those unnecessary strings?
you can try using the checkout parameters instead
checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'RelativeTargetDirectory', relativeTargetDir: 'subdirectory1']], submoduleCfg: [], userRemoteConfigs: [[url: 'repo1.git']]])