0

I have a declarative pipeline that uses a kubernetes agent.

pipeline {
    agent {
        kubernetes {
            yamlFile "file.yml"
        }
    }
...
}

The pipeline is started by a Gerrit trigger, the GERRIT_REFSPEC parameter is provided by this trigger.

During scm git checkout a first git fetch is made successfully (GERRIT_RESPEC is recognized), the second one fails (GERRIT_RESPEC is NOT recognized).

Triggered by Gerrit: https://[gerrit-server]
Checking out git ssh://[gerrit-server]/[project] into [workspace] to read Jenkinsfile
Selected Git installation does not exist. Using Default
The recommended git tool is: NONE
using credential gerrit
 > git rev-parse --resolve-git-dir [workspace]/.git # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url ssh://[gerrit-server]/[project] # timeout=10
Fetching upstream changes from ssh://[gerrit-server]/[project]
 > git --version # timeout=10
 > git --version # 'git version 2.30.2'
using GIT_SSH to set credentials [gerrit-server]
 > git fetch --tags --force --progress -- ssh://[gerrit-server]/[project] refs/changes/11/111111/11:refs/changes/11/111111/11 # timeout=10
 > git rev-parse refs/remotes/origin/refs/changes/11/111111/11^{commit} # timeout=10
 > git rev-parse refs/changes/11/111111/11^{commit} # timeout=10
Checking out Revision [revision-id] (refs/changes/11/111111/11)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f [revision-id] # timeout=10
Commit message: "[commit-message]"
First time build. Skipping changelog.
Running in Durability level: MAX_SURVIVABILITY
hudson.plugins.git.GitException: Command "git fetch --tags --force --progress --prune -- origin +refs/heads/$GERRIT_REFSPEC:refs/remotes/origin/$GERRIT_REFSPEC" returned status code 128:
stdout: 
stderr: fatal: couldn't find remote ref refs/heads/$GERRIT_REFSPEC
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2681)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:2102)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:86)
    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:624)
    at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:365)
    at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:197)
    at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:173)
    at org.jenkinsci.plugins.workflow.multibranch.ReadTrustedStep$Execution.run(ReadTrustedStep.java:101)
    at org.jenkinsci.plugins.workflow.multibranch.ReadTrustedStep$Execution.run(ReadTrustedStep.java:82)
    at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
    at hudson.security.ACL.impersonate2(ACL.java:449)
    at hudson.security.ACL.impersonate(ACL.java:461)
    at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:829)
Finished: FAILURE

I've seen some other suggestions to disable Lightweight checkout option, but this is already disabled in my case.

If I use a node label (node being manually added to Jenkins) instead of kubernetes the scm git checkout phase succeeds.

agent { label [physical-node-label] }

Is there any way to have the scm git checkout phase succeeded with a Kubernetes agent, without changing the pipeline from declarative to scripting?

Versions used:

Ciprian Vintea
  • 448
  • 2
  • 4
  • 18

2 Answers2

0

In the "git fetch" command which worked, the following parameter was used:

refs/changes/11/111111/11:refs/changes/11/111111/11

This is the same as:

$GERRIT_REFSPEC:$GERRIT_REFSPEC

Which is the correct way to perform the fetch.

But in the failed "git fetch" command, the following parameter was used:

refs/heads/$GERRIT_REFSPEC:refs/remotes/origin/$GERRIT_REFSPEC

Which will be replace to:

refs/heads/refs/changes/11/111111/11:refs/remotes/origin/refs/changes/11/111111/11

Which is totally wrong.

I don't know why this is happening :-(

Marcelo Ávila de Oliveira
  • 19,950
  • 3
  • 39
  • 50
  • I saw that the refs/heads/ is automatically added if our value contains only the branch (not the full path, like refs/*). If our value contains the full path (refs/changes/11/111111/11) the refs/heads is removed. Because the param $GERRIT_REFSPEC was not recognized the plugin prepended refs/heads/. So, with the right value for $GERRIT_REFSPEC I would expect the both fetches to be simillar. – Ciprian Vintea Sep 09 '21 at 14:04
  • https://issues.jenkins.io/plugins/servlet/mobile#issue/JENKINS-49757 This ticket was release with git plugin version 4.4.0. Even it is released I still have two fetches (Preserve second fetch option (https://github.com/jenkinsci/git-plugin/pull/927) being unchecked. – Ciprian Vintea Sep 09 '21 at 19:13
0

After multiple attempts I was able to "solve" the problem by adding the yaml content directly in groovy instead of using yamlFile. I would have preferred to have the yaml outside, but I have to continue with it inside due to this error.

Ciprian Vintea
  • 448
  • 2
  • 4
  • 18