Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-63581

GIT checkout fails with [Couldn't find any revision to build] when branch specifier is commit ID

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      Jenkins ver. 2.195
      Git client plugin ver. 3.2.1
      Git plugin ver. 4.2.2
    • Similar Issues:

      Description

      We execute one and the same job config.xml both on Linux and Windows slaves. 

      It uses a commit ID as a branch specifier. This configuration works perfectly on Linux but it fails on Windows. 

      I see double quotes are added to the commit ID on Windows, but I am not sure if that causes the problem.

      Failing windows output:

      Building remotely on sofumwin04.eur.ad.sag
      (.NET3.5 doxygen1.8.5 git cppcheck .NET4.5 cmake nodejs perl windows) in workspace C:/jenkins/workspace/freestyle_checkout
      No credentials specified
      > C:\jenkins\tools\git\cmd\git.exe rev-parse --is-inside-work-tree # timeout=10
      Fetching changes from the remote Git repository
      > C:\jenkins\tools\git\cmd\git.exe config remote.origin.url http://irepo.eur.ad.sag/scm/tsm/um-test.git

      1. timeout=10
        Cleaning workspace
        > C:\jenkins\tools\git\cmd\git.exe rev-parse --verify HEAD # timeout=10
        Resetting working tree
        > C:\jenkins\tools\git\cmd\git.exe reset --hard # timeout=10
        > C:\jenkins\tools\git\cmd\git.exe clean -ffdx # timeout=10
        > C:\jenkins\tools\git\cmd\git.exe submodule foreach --recursive git reset --hard # timeout=10
        > C:\jenkins\tools\git\cmd\git.exe submodule foreach --recursive git clean -fdx # timeout=10
        Fetching upstream changes from http://irepo.eur.ad.sag/scm/tsm/um-test.git
        > C:\jenkins\tools\git\cmd\git.exe --version # timeout=10
        > C:\jenkins\tools\git\cmd\git.exe fetch --tags --force --progress – http://irepo.eur.ad.sag/scm/tsm/um-test.git
        +refs/heads/:refs/remotes/origin/ # timeout=10
        > C:\jenkins\tools\git\cmd\git.exe rev-parse "22a341d6223157c1e1b2db792c26eb007f80d64a^{commit}" # timeout=10
        > C:\jenkins\tools\git\cmd\git.exe rev-parse "origin/22a341d6223157c1e1b2db792c26eb007f80d64a^{commit}" # timeout=10
        > C:\jenkins\tools\git\cmd\git.exe rev-parse "22a341d6223157c1e1b2db792c26eb007f80d64a^{commit}" # timeout=10
        ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
        Finished: FAILURE
         
         
        Working Linux output: 
      2. Building remotely on sofumrhel02.eur.ad.sag
        (rdma cmake linux gcc4.8.5 rhel7.5) in workspace /home/vmtest/workspace/freestyle_checkout
        Installer "Extract .zip/.tar.gz" cannot be used to install "git-2.28.0" on the node "sofumrhel02.eur.ad.sag"
        No credentials specified
        Cloning the remote Git repository
        Cloning repository http://irepo.eur.ad.sag/scm/tsm/um-test.git
        > git init /home/vmtest/workspace/freestyle_checkout # timeout=10
        Fetching upstream changes from http://irepo.eur.ad.sag/scm/tsm/um-test.git
        > git --version # timeout=10
        > git fetch --tags --progress http://irepo.eur.ad.sag/scm/tsm/um-test.git
        +refs/heads/:refs/remotes/origin/ # timeout=10
        > git config remote.origin.url http://irepo.eur.ad.sag/scm/tsm/um-test.git
      1. timeout=10
        > git config --add remote.origin.fetch +refs/heads/:refs/remotes/origin/ # timeout=10
        > git config remote.origin.url http://irepo.eur.ad.sag/scm/tsm/um-test.git
      2. timeout=10
        Cleaning workspace
        > git rev-parse --verify HEAD # timeout=10
        No valid HEAD. Skipping the resetting
        > git clean -ffdx # timeout=10
        Fetching upstream changes from http://irepo.eur.ad.sag/scm/tsm/um-test.git
        > git fetch --tags --progress http://irepo.eur.ad.sag/scm/tsm/um-test.git
        +refs/heads/:refs/remotes/origin/ # timeout=10
        > git rev-parse 22a341d6223157c1e1b2db792c26eb007f80d64a^{commit} # timeout=10
        Checking out Revision 22a341d6223157c1e1b2db792c26eb007f80d64a (detached)
        > git config core.sparsecheckout # timeout=10
        > git checkout -f 22a341d6223157c1e1b2db792c26eb007f80d64a # timeout=10
        Commit message: "Auto-update submodule reference using gradle-git-submodules job, pointing to master"
        > git rev-list --no-walk 22a341d6223157c1e1b2db792c26eb007f80d64a # timeout=10
        > git remote # timeout=10
        > git submodule init # timeout=10
        > git submodule sync # timeout=10
        > git config --get remote.origin.url # timeout=10
        Using shallow submodule update with depth 1
        > git submodule init # timeout=10
        [WARNING] Git client older than 1.8.4 doesn't support shallow submodule updates. This flag is ignored.
        > git config -f .gitmodules --get-regexp ^submodule\.(.+)\.url # timeout=10
        > git config --get submodule.gradle.url # timeout=10
        > git config -f .gitmodules --get submodule.gradle.path # timeout=10
        > git submodule update --init --recursive gradle # timeout=10
        Finished: SUCCESS
         

      Could it be a configuration issue on my side? I cannot say :/

        Attachments

        1. config.xml
          3 kB
          Vassilena Treneva

          Activity

          Hide
          markewaite Mark Waite added a comment - - edited

          One common case of "Couldn't find any revision to build" is because the commit with the SHA-1 mentioned in the message is not available inside the workspace on the agent. If you can access the agent workspace after the job has failed, you could confirm that the SHA-1 mentioned in the message exists in the workspace on the agent. The command {{git log 22a341d6223157c1e1b2db792c26eb007f80d64a }} in the agent workspace should provide the same output on the Linux agent and the Windows agent.

          If they don't have the same output on Windows and Linux, then the usage of the two workspaces may have been different. For example, sometimes an existing agent workspace is reused and it contains that SHA-1 and other times a new agent workspace is created and the SHA-1 is not available, either because the fetch did not copy it or because it does not exist in the central repository.

          As a separate note, that might possibly be related, the message warning about git client older than git 1.8.4 and the message that the Linux agent is running on RHEL 7 may be indicators that the command line git version on the RHEL 7 machine should be considered for upgrade. RHEL 7 ships command line git 1.8 by default. That is a 6 year old version of command line git. I suspect that the command line git version on the Windows computer is much newer. Git 2.28.0 is the current release of command line git. It includes many capabilities that are not available in command line git 1.8 as shipped with RHEL 7.

          The double quotes on Windows are not likely to be a problem. The Windows command interpreter treats the "^" character as a special character. When the git plugin passes the string

          "SHA-1^{commit}"
          

          to command line git on Windows, it must surround that argument in double quotes so that the "^" is not processed by the command interpreter as a special character.

          Show
          markewaite Mark Waite added a comment - - edited One common case of "Couldn't find any revision to build" is because the commit with the SHA-1 mentioned in the message is not available inside the workspace on the agent. If you can access the agent workspace after the job has failed, you could confirm that the SHA-1 mentioned in the message exists in the workspace on the agent. The command {{git log 22a341d6223157c1e1b2db792c26eb007f80d64a }} in the agent workspace should provide the same output on the Linux agent and the Windows agent. If they don't have the same output on Windows and Linux, then the usage of the two workspaces may have been different. For example, sometimes an existing agent workspace is reused and it contains that SHA-1 and other times a new agent workspace is created and the SHA-1 is not available, either because the fetch did not copy it or because it does not exist in the central repository. As a separate note, that might possibly be related, the message warning about git client older than git 1.8.4 and the message that the Linux agent is running on RHEL 7 may be indicators that the command line git version on the RHEL 7 machine should be considered for upgrade. RHEL 7 ships command line git 1.8 by default. That is a 6 year old version of command line git. I suspect that the command line git version on the Windows computer is much newer. Git 2.28.0 is the current release of command line git. It includes many capabilities that are not available in command line git 1.8 as shipped with RHEL 7. The double quotes on Windows are not likely to be a problem. The Windows command interpreter treats the "^" character as a special character. When the git plugin passes the string "SHA-1^{commit}" to command line git on Windows, it must surround that argument in double quotes so that the "^" is not processed by the command interpreter as a special character.
          Hide
          vassilena Vassilena Treneva added a comment - - edited

          Indeed, looks like the checked out copies are different.

          Windows:
          C:\jenkins\workspace\freestyle_checkout>C:\jenkins\tools\git\cmd\git.exe log 22a
          341d6223157c1e1b2db792c26eb007f80d64a
          fatal: bad object 22a341d6223157c1e1b2db792c26eb007f80d64a

          Linux:
          [vmtest@sofumrhel02 freestyle_checkout]$ git log 22a341d6223157c1e1b2db792c26eb0 07f80d64a
          commit 22a341d6223157c1e1b2db792c26eb007f80d64a
          Author: Build SAG
          Date: Tue Sep 1 16:37:11 2020 +0200

          But how is that possible since both configurations are starting from a clean workspace and the checkout job config is the same for both?

          (and yes, our git client on the RHEL machines is significantly older that then windows one - the reason is that the newer windows client is easily installed using Jenkins zip auto-installers but GIT is providing zip binary distro only for Windows, looks like they ceased providing binaries zip for Linux: https://github.com/GoogleCloudPlatform/gcsfuse/issues/162)

          Show
          vassilena Vassilena Treneva added a comment - - edited Indeed, looks like the checked out copies are different. Windows : C:\jenkins\workspace\freestyle_checkout>C:\jenkins\tools\git\cmd\git.exe log 22a 341d6223157c1e1b2db792c26eb007f80d64a fatal: bad object 22a341d6223157c1e1b2db792c26eb007f80d64a Linux : [vmtest@sofumrhel02 freestyle_checkout] $ git log 22a341d6223157c1e1b2db792c26eb0 07f80d64a commit 22a341d6223157c1e1b2db792c26eb007f80d64a Author: Build SAG Date: Tue Sep 1 16:37:11 2020 +0200 But how is that possible since both configurations are starting from a clean workspace and the checkout job config is the same for both? (and yes, our git client on the RHEL machines is significantly older that then windows one - the reason is that the newer windows client is easily installed using Jenkins zip auto-installers but GIT is providing zip binary distro only for Windows, looks like they ceased providing binaries zip for Linux: https://github.com/GoogleCloudPlatform/gcsfuse/issues/162 )
          Hide
          markewaite Mark Waite added a comment -

          The job definition you uploaded as config.xml includes the "clean before checkout" behavior but does not include the "wipe workspace" behavior. The "clean before checkout" behavior retains the existing git repository (the .git directory) but removes untracked files. It does that with the git clean -xfd command.

          If the workspace had been previously populated with repository content, the "clean before checkout" does not remove that previously created content. The git plugin tries to reduce data transfer by retaining the git repository across multiple builds in the same workspace. You would need to add "Wipe workspace" to assure that the two workspaces have the same content.

          If wipe workspace still shows a difference, then it is likely that there is a difference due to the two versions of command line git being used.

          Show
          markewaite Mark Waite added a comment - The job definition you uploaded as config.xml includes the "clean before checkout" behavior but does not include the "wipe workspace" behavior. The "clean before checkout" behavior retains the existing git repository (the .git directory) but removes untracked files. It does that with the git clean -xfd command. If the workspace had been previously populated with repository content, the "clean before checkout" does not remove that previously created content. The git plugin tries to reduce data transfer by retaining the git repository across multiple builds in the same workspace. You would need to add "Wipe workspace" to assure that the two workspaces have the same content. If wipe workspace still shows a difference, then it is likely that there is a difference due to the two versions of command line git being used.
          Hide
          markewaite Mark Waite added a comment -

          Alex Vasilkov did you find a solution to the issue? Should this be closed? If not, can you provide more details on the failure?

          Show
          markewaite Mark Waite added a comment - Alex Vasilkov did you find a solution to the issue? Should this be closed? If not, can you provide more details on the failure?
          Hide
          vassilena Vassilena Treneva added a comment -

          Making sure the workspace is deleted before starting the checkout operation worked for me.

          Show
          vassilena Vassilena Treneva added a comment - Making sure the workspace is deleted before starting the checkout operation worked for me.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            vassilena Vassilena Treneva
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: