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

Git should include an option to "checkout the revision at build-time"

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None

      Currently the git-plugin can checkout the current head, or a specific commit, what I'm missing is an option to checkout the head at the time where the build has started.

      Reason: if you have a pipeline build that was triggered at a certain time, and the devlopers checked in something before the checkout takes place these changes are picked up even if the build is already running for a while.

      For example I have a pipeline that builds different repositories together one after the other. It now can happen that a build starts, checkout the first repository, then checkout the second but picks up changes commited at a later point at time (and fail because changes from the first repository are not taken into account).

      The same happens if you replay a certain pipeline build, it always fetches the ltest changes and not the changes that where current at the time of the build (so replay is more a "rebuild with different script" because the build is not really replayed.

          [JENKINS-59071] Git should include an option to "checkout the revision at build-time"

          Dan Alvizu added a comment -

          I'm a bit confused if this is a bug or a feature request:

           

          Jenkins docs describe:

          https://jenkins.io/doc/book/pipeline/jenkinsfile/

          The checkout step will checkout code from source control; scm is a special variable which instructs the checkout step to clone the specific revision which triggered this Pipeline run.

           
          In this scenario:
          1) Commit to master commit sha abc
          2) Block pipeline on manual step or whatever, `checkout scm` will checkout abc
          3) Push new commit, sha xyz
          3) resume pipeline
          4) later pipeline stage also runs `checkout scm`
           
          Do you expect abc or xyz? Per docs I would expect xyz?
           
          In your scenario, you are:
          1) commit to master commit sha abc
          2) build triggered, jenkins starts its thing
          3) before `checkout scm` run, push another commit xyz
           
          And you're observing 'xyz' is checked out and not 'abc'? Is that accurate?
           

          Dan Alvizu added a comment - I'm a bit confused if this is a bug or a feature request:   Jenkins docs describe: https://jenkins.io/doc/book/pipeline/jenkinsfile/ The  checkout  step will checkout code from source control;  scm  is a special variable which instructs the  checkout  step to clone the specific revision which triggered this Pipeline run.   In this scenario: 1) Commit to master commit sha abc 2) Block pipeline on manual step or whatever, `checkout scm` will checkout abc 3) Push new commit, sha xyz 3) resume pipeline 4) later pipeline stage also runs `checkout scm`   Do you expect abc or xyz? Per docs I would expect xyz?   In your scenario, you are: 1) commit to master commit sha abc 2) build triggered, jenkins starts its thing 3) before `checkout scm` run, push another commit xyz   And you're observing 'xyz' is checked out and not 'abc'? Is that accurate?  

          Thanks for taking a look into this, from my point of view I won't say it is a bug but more a feature request, that's why I marked it as a new function, and would expect to find it as a new behavior or maybe added to the 'advanced checkout behaviors'.
          Our build combines artifacts from different source repositories int one final artifact, for different reasons we can't just merge them or build them independently, but beside from that the case can be generalized to have two source.repositories Master + Child:

          • Master contains a Jenkinsfile and is used in a multi-branch-pipeline, and uses 'checkout scm'
          • The Jenkinsfile of Master later on contains 'checkout scm Child'

          a Jenkinsfile might look something like this:

          steps {
          	checkout([$class: 'GitSCM', branches: [[name: '*/master']], userRemoteConfigs: [[url: 'http://master/repro']]])
          	sh 'mvn clean install master/pom.xml'
          	checkout([$class: 'GitSCM', branches: [[name: '*/master']], userRemoteConfigs: [[url: 'http://child/repro']]])
          	sh 'mvn clean install child/pom.xml'
          	sh 'aggregation.sh'
          }
          

          What happens now is, that while the part in Jenkinsfile is running before the 'checkout scm Child' someone pushes a new commit to Child and when the pipeline reaches that step it fetches the new commit and thus building 'Child' in a different (from the point of happens-before-relation) version than 'Master'

          So what would be needed is some kind of checkout behavior that not checkouts 'specific revision which triggered this Pipeline run but checkouts 'most recent revision when the build starts', something like

          git checkout 'master@{BUILD_DATE}'

          Christoph Läubrich added a comment - Thanks for taking a look into this, from my point of view I won't say it is a bug but more a feature request, that's why I marked it as a new function, and would expect to find it as a new behavior or maybe added to the 'advanced checkout behaviors'. Our build combines artifacts from different source repositories int one final artifact, for different reasons we can't just merge them or build them independently, but beside from that the case can be generalized to have two source.repositories Master + Child: Master contains a Jenkinsfile and is used in a multi-branch-pipeline, and uses 'checkout scm' The Jenkinsfile of Master later on contains 'checkout scm Child' a Jenkinsfile might look something like this: steps { checkout([$class: 'GitSCM' , branches: [[name: '*/master' ]], userRemoteConfigs: [[url: 'http: //master/repro' ]]]) sh 'mvn clean install master/pom.xml' checkout([$class: 'GitSCM' , branches: [[name: '*/master' ]], userRemoteConfigs: [[url: 'http: //child/repro' ]]]) sh 'mvn clean install child/pom.xml' sh 'aggregation.sh' } What happens now is, that while the part in Jenkinsfile is running before the 'checkout scm Child' someone pushes a new commit to Child and when the pipeline reaches that step it fetches the new commit and thus building 'Child' in a different (from the point of happens-before-relation) version than 'Master' So what would be needed is some kind of checkout behavior that not checkouts 'specific revision which triggered this Pipeline run but checkouts 'most recent revision when the build starts', something like git checkout 'master@{BUILD_DATE}'

          Isn't that something resolveScm() can help with?

          Tobias Gruetzmacher added a comment - Isn't that something resolveScm() can help with?

          tgr thanks for taking care of this, maybe CloneOption/reference is usefull but from the documentation I can't guess how it is supposed to work :-\
          There is also a CloneOptionTrait/reference but no idea whats the deffirence...?

          Christoph Läubrich added a comment - tgr thanks for taking care of this, maybe CloneOption/reference is usefull but from the documentation I can't guess how it is supposed to work :-\ There is also a CloneOptionTrait/reference but no idea whats the deffirence...?

            Unassigned Unassigned
            laeubi Christoph Läubrich
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: