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

SCM steps should return revision state

    XMLWordPrintable

Details

    Description

      The return value of the git step should be the commit hash, etc., and there should be a way to pass that back in to a subsequent git step in case you want to check out the same revision in another workspace (without copying files).

      The workaround is to archive and then unarchive sources.

      Attachments

        Issue Links

          Activity

            jglick Jesse Glick added a comment -

            Requires some kind of enhanced API from SCM.

            jglick Jesse Glick added a comment - Requires some kind of enhanced API from SCM .

            Not just for GIT, please. We have a similar use case for other SCMs, too.

            tg9541 Thomas Goeppel added a comment - Not just for GIT, please. We have a similar use case for other SCMs, too.
            jglick Jesse Glick added a comment -

            Sure, I was just using Git as an example.

            jglick Jesse Glick added a comment - Sure, I was just using Git as an example.
            jglick Jesse Glick added a comment -

            Features in scm-api (as in JENKINS-26129) might be enough to both determine the current tip, and preconfigure an SCM to check that out.

            jglick Jesse Glick added a comment - Features in scm-api (as in JENKINS-26129 ) might be enough to both determine the current tip, and preconfigure an SCM to check that out.
            danielbeck Daniel Beck added a comment -

            Related: Subversion Plugin has RevisionParameterAction to build a predetermined revision.

            danielbeck Daniel Beck added a comment - Related: Subversion Plugin has RevisionParameterAction to build a predetermined revision.
            jglick Jesse Glick added a comment -

            Good to know, though the more generic approach would be to take advantage of the logic in SubversionSCMSource.build.

            jglick Jesse Glick added a comment - Good to know, though the more generic approach would be to take advantage of the logic in SubversionSCMSource.build .

            Just to mention another workaround on this topic.

            You can also pipe the current revision into a file and archive that file to be reused later on in the workflow instead of the complete source code.

            nexus49 Bastian Echterhoelter added a comment - Just to mention another workaround on this topic. You can also pipe the current revision into a file and archive that file to be reused later on in the workflow instead of the complete source code.
            jglick Jesse Glick added a comment -

            Or just pipe into a file and readFile it as a string.

            jglick Jesse Glick added a comment - Or just pipe into a file and readFile it as a string.
            robjailall Robert Jay added a comment -

            Also interested in this. We use something like this for integrations, where if someone commits a change to a shared library, we want to use that version of the shared library in integration tests with downstream projects that use the library.

            robjailall Robert Jay added a comment - Also interested in this. We use something like this for integrations, where if someone commits a change to a shared library, we want to use that version of the shared library in integration tests with downstream projects that use the library.
            jglick Jesse Glick added a comment -

            robjailall if you use a multibranch flow (JENKINS-26129) you get this out of the box, assuming the logic is all in one job.

            jglick Jesse Glick added a comment - robjailall if you use a multibranch flow ( JENKINS-26129 ) you get this out of the box, assuming the logic is all in one job.
            jglick Jesse Glick added a comment -

            JENKINS-31386 would also help for the common case of checking out the script from the same repository.

            jglick Jesse Glick added a comment - JENKINS-31386 would also help for the common case of checking out the script from the same repository.

            I tried Pipeline and Multibranch Pipeline options with Jenkins 2.0 alpha-3, but env.SVN_REVISION was null:

            • New Item -> Pipeline -> Pipeline Script:
              node {
                 checkout scm: [$class: 'SubversionSCM', locations: [[ remote:'https://svn.mycompany.com/repos/mw/maventest/trunk', credentialsId: '...', local: '.']]]
                 println 'env.SVN_REVISION: ' + env.SVN_REVISION
              }
              
            • New Item -> Pipeline -> Pipeline from SCM -> SCM: Subversion -> Repository URL: https://svn.mycompany.com/repos/mw/maventest/trunk, Credentials: ..., Script Path: Jenkinsfile
              Jenkinsfile
              node {
                 println 'env.SVN_REVISION: ' + env.SVN_REVISION
              }
              
            • New Item -> Multibranch Pipeline -> Branch Sources: Subversion -> Project Repository Base: https://svn.mycompany.com/repos/mw/maventest, Credentials: ..., Include branches: trunk
              Jenkinsfile
              node {
                 println 'env.SVN_REVISION: ' + env.SVN_REVISION
              }
              
            as_kumlali Ali Sadik Kumlali added a comment - I tried Pipeline and Multibranch Pipeline options with Jenkins 2.0 alpha-3, but env.SVN_REVISION was null: New Item -> Pipeline -> Pipeline Script: node { checkout scm: [$class: 'SubversionSCM' , locations: [[ remote: 'https: //svn.mycompany.com/repos/mw/maventest/trunk' , credentialsId: '...' , local: '.' ]]] println 'env.SVN_REVISION: ' + env.SVN_REVISION } New Item -> Pipeline -> Pipeline from SCM -> SCM: Subversion -> Repository URL: https://svn.mycompany.com/repos/mw/maventest/trunk , Credentials: ..., Script Path: Jenkinsfile Jenkinsfile node { println 'env.SVN_REVISION: ' + env.SVN_REVISION } New Item -> Multibranch Pipeline -> Branch Sources: Subversion -> Project Repository Base: https://svn.mycompany.com/repos/mw/maventest , Credentials: ..., Include branches: trunk Jenkinsfile node { println 'env.SVN_REVISION: ' + env.SVN_REVISION }
            jglick Jesse Glick added a comment -

            Yes, as documented under env in Pipeline Syntax » Global Variables this is not yet supported. You need to git rev-parse HEAD etc.

            jglick Jesse Glick added a comment - Yes, as documented under env in Pipeline Syntax » Global Variables this is not yet supported. You need to git rev-parse HEAD etc.
            jglick Jesse Glick added a comment -

            For a multibranch Pipeline job (Jenkinsfile), it would be straightforward to expose the SCMRevision as a special Groovy variable, as it is Serializable. Depending on the SCM source, you will get various available properties, such as hash in the case of Git branches (JENKINS-33161 would offer pullHash for pull request builds), though these would need to be marked @Whitelisted too.

            For general use including non-multibranch builds it would be desirable to get variables generically from the checkout step though this would require a core API change (JENKINS-24141). For the case of the git and svn convenience steps these could directly return the revision.

            jglick Jesse Glick added a comment - For a multibranch Pipeline job ( Jenkinsfile ), it would be straightforward to expose the SCMRevision as a special Groovy variable, as it is Serializable . Depending on the SCM source, you will get various available properties, such as hash in the case of Git branches ( JENKINS-33161 would offer pullHash for pull request builds), though these would need to be marked @Whitelisted too. For general use including non-multibranch builds it would be desirable to get variables generically from the checkout step though this would require a core API change ( JENKINS-24141 ). For the case of the git and svn convenience steps these could directly return the revision.
            zaytsev_work Yury Zaytsev added a comment -

            I understand that this is still not implemented, therefore one needs to go the rev-parse way, but is there a possibility to modify scm object to use the correct revision, instead of making a brand new one, like

            checkout([$class: 'GitSCM', branches: [[name: 'XXX']], extensions: [[$class: 'SubmoduleOption', parentCredentials: true], [$class: 'CleanCheckout']], userRemoteConfigs: [[credentialsId: 'YYY', url: 'ZZZ']]])
            

            and basically have to duplicate all the SCM settings? Sorry for a newb Groovy question, if this is trivial.

            zaytsev_work Yury Zaytsev added a comment - I understand that this is still not implemented, therefore one needs to go the rev-parse way, but is there a possibility to modify scm object to use the correct revision, instead of making a brand new one, like checkout([$class: 'GitSCM' , branches: [[name: 'XXX' ]], extensions: [[$class: 'SubmoduleOption' , parentCredentials: true ], [$class: 'CleanCheckout' ]], userRemoteConfigs: [[credentialsId: 'YYY' , url: 'ZZZ' ]]]) and basically have to duplicate all the SCM settings? Sorry for a newb Groovy question, if this is trivial.
            jglick Jesse Glick added a comment -

            modify scm object to use the correct revision

            If by “correct revision” you just mean “the same revision I checked out somewhere earlier in the build”, then for multibranch Pipelines this is automatic when you do checkout scm. For simple projects using CpsScmFlowDefinition it is not possible due to limitations in the SCM API; it would be possible to provide an alternate FlowDefinition that uses scm-api, i.e. branch sources, and which provides the same guarantee of a consistent revision across calls to checkout scm.

            jglick Jesse Glick added a comment - modify scm object to use the correct revision If by “correct revision” you just mean “the same revision I checked out somewhere earlier in the build”, then for multibranch Pipelines this is automatic when you do checkout scm . For simple projects using CpsScmFlowDefinition it is not possible due to limitations in the SCM API; it would be possible to provide an alternate FlowDefinition that uses scm-api , i.e. branch sources, and which provides the same guarantee of a consistent revision across calls to checkout scm .
            zaytsev_work Yury Zaytsev added a comment -

            > If by “correct revision” you just mean “the same revision I checked out somewhere earlier in the build”, then for multibranch Pipelines this is automatic when you do checkout scm.

            I'm very surprised to hear that. Multibranch pipeline project is exactly what I have. In my pipeline, I have multiple stages, which all do checkout scm for now, and inside each stage I have checkouts on multiple workers in parallel. The pipeline currently runs for an hour, or so, and if someone commits when the pipeline is already running, the checkout scm in the next stage picks up new commits, and not the commit with which the pipeline has been started.

            I want checkout scm to always checkout the commit which triggered the build, and not the branch which triggered the build, whatever the branch state is. Please see a screenshot attached...

            zaytsev_work Yury Zaytsev added a comment - > If by “correct revision” you just mean “the same revision I checked out somewhere earlier in the build”, then for multibranch Pipelines this is automatic when you do checkout scm. I'm very surprised to hear that. Multibranch pipeline project is exactly what I have. In my pipeline, I have multiple stages, which all do checkout scm for now, and inside each stage I have checkouts on multiple workers in parallel. The pipeline currently runs for an hour, or so, and if someone commits when the pipeline is already running, the checkout scm in the next stage picks up new commits, and not the commit with which the pipeline has been started. I want checkout scm to always checkout the commit which triggered the build, and not the branch which triggered the build, whatever the branch state is. Please see a screenshot attached...
            zaytsev_work Yury Zaytsev added a comment -

            Just to clarify what you see on the screenshot: first it started building revision 3dc9d2b (1 commits since the last build), but then someone merged another branch while the pipeline was running, and checkout scm in the later stages picked up the new state 0825e24 (4 commits more), which is two merge commits away from the last build. Now, in the meantime, build #83 has been triggered with 0825e24, and both kept running in parallel, which, of course, doesn't make any sense.

            Ideally, I would like newer builds to abort previous ones as they get to the end of the stage, but, in the mean time, at least checkout scm should always checkout the same thing within one build.

            So, thank you for answering, but I can't see how what you're saying is correct.

            zaytsev_work Yury Zaytsev added a comment - Just to clarify what you see on the screenshot: first it started building revision 3dc9d2b (1 commits since the last build), but then someone merged another branch while the pipeline was running, and checkout scm in the later stages picked up the new state 0825e24 (4 commits more), which is two merge commits away from the last build. Now, in the meantime, build #83 has been triggered with 0825e24 , and both kept running in parallel, which, of course, doesn't make any sense. Ideally, I would like newer builds to abort previous ones as they get to the end of the stage, but, in the mean time, at least checkout scm should always checkout the same thing within one build. So, thank you for answering, but I can't see how what you're saying is correct.

            why are you not using stash? checkout once, stash files, and then unstash in multiple times on nodes and stages.

            jarosite aleksey savitskiy added a comment - why are you not using stash? checkout once, stash files, and then unstash in multiple times on nodes and stages.
            zaytsev_work Yury Zaytsev added a comment -

            jarosite my repository is ~2G large and I have lots of small files in it. Very unfortunately, stash is simply not usable for anything beyond a couple of dozens of megabytes and hundreds of files.

            zaytsev_work Yury Zaytsev added a comment - jarosite my repository is ~2G large and I have lots of small files in it. Very unfortunately, stash is simply not usable for anything beyond a couple of dozens of megabytes and hundreds of files.
            jglick Jesse Glick added a comment -

            if someone commits when the pipeline is already running, the checkout scm in the next stage picks up new commits, and not the commit with which the pipeline has been started

            Then that is a bug, which should be filed separately with complete, self-contained steps to reproduce from scratch. The version consistency guarantee of checkout scm does have test coverage, including of course for Git.

            I want checkout scm to always checkout the commit which triggered the build

            Well there is not necessarily any such commit, or unique commit. What is guaranteed is that the repository revision from which Jenkinsfile was loaded whenever the build actually started running will match that of any subsequent checkout scm commands.

            jglick Jesse Glick added a comment - if someone commits when the pipeline is already running, the checkout scm in the next stage picks up new commits, and not the commit with which the pipeline has been started Then that is a bug, which should be filed separately with complete, self-contained steps to reproduce from scratch. The version consistency guarantee of checkout scm does have test coverage, including of course for Git. I want checkout scm to always checkout the commit which triggered the build Well there is not necessarily any such commit, or unique commit. What is guaranteed is that the repository revision from which Jenkinsfile was loaded whenever the build actually started running will match that of any subsequent checkout scm commands.
            mcobden Marcus Cobden added a comment -

            I'm seeing the issue where `checkout scm` results in different commits between the start/end of a build; I've made a separate bug with a reproduction example: https://issues.jenkins-ci.org/browse/JENKINS-39508

            mcobden Marcus Cobden added a comment - I'm seeing the issue where `checkout scm` results in different commits between the start/end of a build; I've made a separate bug with a reproduction example: https://issues.jenkins-ci.org/browse/JENKINS-39508
            jglick Jesse Glick added a comment -

            My running proposal FTR:

            For freestyle projects, there is ≤1 SCM, so we just set build-wide environment variables, and unless you are using the multi-SCM plugin which barely works, you are fine. For Pipeline, we could do the same if JENKINS-42499 were fixed, but the result will be useless for >1 (distinct) checkout. So while the core API might simply be widened to accept Run rather than AbstractBuild (JENKINS-24141), I would suggest having SCMStep return a Map<String,String> (perhaps) rather than set actual environment variables. Thus you could write, for example:

            def sha1 = checkout(scm).GIT_COMMIT
            
            jglick Jesse Glick added a comment - My running proposal FTR: For freestyle projects, there is ≤1 SCM , so we just set build-wide environment variables, and unless you are using the multi-SCM plugin which barely works, you are fine. For Pipeline, we could  do the same if JENKINS-42499 were fixed, but the result will be useless for >1 (distinct) checkout . So while the core API might simply be widened to accept Run  rather than AbstractBuild ( JENKINS-24141 ), I would suggest having SCMStep  return a Map<String,String>  (perhaps) rather than set actual environment variables. Thus you could write, for example: def sha1 = checkout(scm).GIT_COMMIT
            abayer Andrew Bayer added a comment -

            fwiw, that'd still probably need buildEnvVars(Run,Map) anyway to get the map in the first place, wouldn't it? Just that we'd be returning the Map rather than adding it to an existing EnvVars.

            abayer Andrew Bayer added a comment - fwiw, that'd still probably need buildEnvVars(Run,Map) anyway to get the map in the first place, wouldn't it? Just that we'd be returning the Map rather than adding it to an existing EnvVars .
            abayer Andrew Bayer added a comment -

            Actually, thinking about it more, maybe the right approach is to write off the legacy SCMs and just worry about implementations of SCMStep other than GenericSCMStep, offloading the decision as to whether to reuse code across about SomeSCM.buildEnvVars(AbstractBuild,Map) and SomeSCMStep.

            abayer Andrew Bayer added a comment - Actually, thinking about it more, maybe the right approach is to write off the legacy SCMs and just worry about implementations of SCMStep other than GenericSCMStep , offloading the decision as to whether to reuse code across about SomeSCM.buildEnvVars(AbstractBuild,Map) and SomeSCMStep .
            jglick Jesse Glick added a comment -

            that'd still probably need buildEnvVars(Run,Map) anyway to get the map in the first place, wouldn't it?

            Correct, hence the dependency on this aspect of JENKINS-24141.

            just worry about implementations of SCMStep other than GenericSCMStep

            No. The other implementations are semi-deprecated. See JENKINS-37227.

            jglick Jesse Glick added a comment - that'd still probably need buildEnvVars(Run,Map) anyway to get the map in the first place, wouldn't it? Correct, hence the dependency on this aspect of JENKINS-24141 . just worry about implementations of SCMStep other than GenericSCMStep No. The other implementations are semi-deprecated. See  JENKINS-37227 .
            abayer Andrew Bayer added a comment -

            Aaaah, gotcha.

            abayer Andrew Bayer added a comment - Aaaah, gotcha.
            abayer Andrew Bayer added a comment - Various PRs up - Core: https://github.com/jenkinsci/jenkins/pull/2730 Git: https://github.com/jenkinsci/git-plugin/pull/492 SCM step: https://github.com/jenkinsci/workflow-scm-step-plugin/pull/16
            abayer Andrew Bayer added a comment - SVN PR as well - https://github.com/jenkinsci/subversion-plugin/pull/182
            abayer Andrew Bayer added a comment - And here's Mercurial - https://github.com/jenkinsci/mercurial-plugin/pull/102
            abayer Andrew Bayer added a comment -

            FYI, adding a new withCheckout(scm) step as well:

            node {
                withCheckout(scm) {
                     echo "GIT_COMMIT is ${env.GIT_COMMIT}"
                }
            }
            
            abayer Andrew Bayer added a comment - FYI, adding a new withCheckout(scm) step as well: node { withCheckout(scm) { echo "GIT_COMMIT is ${env.GIT_COMMIT}" } }
            jglick Jesse Glick added a comment -

            IIUC this is now Resolved/Fixed towards 2.60, right?

            jglick Jesse Glick added a comment - IIUC this is now Resolved/Fixed towards 2.60, right?
            abayer Andrew Bayer added a comment -

            In core, yes, but not in the various SCMs and `workflow-scm-step`.

            abayer Andrew Bayer added a comment - In core, yes, but not in the various SCMs and `workflow-scm-step`.
            jglick Jesse Glick added a comment -

            Right, point taken.

            jglick Jesse Glick added a comment - Right, point taken.
            jglick Jesse Glick added a comment -

            workflow-job 2.12 has some of this.

            jglick Jesse Glick added a comment - workflow-job 2.12 has some of this.

            Code changed in jenkins
            User: Andrew Bayer
            Path:
            pom.xml
            src/main/java/hudson/plugins/mercurial/MercurialSCM.java
            http://jenkins-ci.org/commit/mercurial-plugin/3592fa40faec68409cda8a05818a4bb853d7da7d
            Log:
            JENKINS-26100 Change buildEnvVars to take Run

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: pom.xml src/main/java/hudson/plugins/mercurial/MercurialSCM.java http://jenkins-ci.org/commit/mercurial-plugin/3592fa40faec68409cda8a05818a4bb853d7da7d Log: JENKINS-26100 Change buildEnvVars to take Run

            Code changed in jenkins
            User: Jesse Glick
            Path:
            pom.xml
            src/main/java/hudson/plugins/mercurial/MercurialSCM.java
            http://jenkins-ci.org/commit/mercurial-plugin/5cc6e1c2b06b57cfa336a781b94bd9db76a0909c
            Log:
            Merge pull request #102 from abayer/jenkins-26100

            JENKINS-26100 Change buildEnvVars to take Run

            Compare: https://github.com/jenkinsci/mercurial-plugin/compare/07ff1c76d51a...5cc6e1c2b06b

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: pom.xml src/main/java/hudson/plugins/mercurial/MercurialSCM.java http://jenkins-ci.org/commit/mercurial-plugin/5cc6e1c2b06b57cfa336a781b94bd9db76a0909c Log: Merge pull request #102 from abayer/jenkins-26100 JENKINS-26100 Change buildEnvVars to take Run Compare: https://github.com/jenkinsci/mercurial-plugin/compare/07ff1c76d51a...5cc6e1c2b06b

            Code changed in jenkins
            User: Joseph
            Path:
            pom.xml
            src/main/java/hudson/plugins/accurev/AccurevSCM.java
            src/main/java/hudson/plugins/accurev/delegates/AbstractModeDelegate.java
            src/main/java/hudson/plugins/accurev/delegates/ReftreeDelegate.java
            src/main/java/hudson/plugins/accurev/delegates/WorkspaceDelegate.java
            src/test/java/hudson/plugins/accurev/AccurevSCMTest.java
            http://jenkins-ci.org/commit/accurev-plugin/5e3008ecc47a6f31930e81223f2b5699121f31cb
            Log:
            JENKINS-26100 Change buildEnvVars to take Run (#55)

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Joseph Path: pom.xml src/main/java/hudson/plugins/accurev/AccurevSCM.java src/main/java/hudson/plugins/accurev/delegates/AbstractModeDelegate.java src/main/java/hudson/plugins/accurev/delegates/ReftreeDelegate.java src/main/java/hudson/plugins/accurev/delegates/WorkspaceDelegate.java src/test/java/hudson/plugins/accurev/AccurevSCMTest.java http://jenkins-ci.org/commit/accurev-plugin/5e3008ecc47a6f31930e81223f2b5699121f31cb Log: JENKINS-26100 Change buildEnvVars to take Run (#55)

            Code changed in jenkins
            User: Andrew Bayer
            Path:
            pom.xml
            src/main/java/hudson/scm/SubversionSCM.java
            src/main/java/jenkins/scm/impl/subversion/SubversionSCMSource.java
            src/test/java/hudson/scm/SubversionSCMUnitTest.java
            http://jenkins-ci.org/commit/subversion-plugin/7696afda51bf2b5cd9a835ccb5014b0eef8dca24
            Log:
            JENKINS-26100 Change buildEnvVars to Run.

            NOTE: Findbugs is disabled due to the fact that there are 33 freakin'
            findbugs warnings that cause the whole build to error out, and fixing
            them is going to take a non-trivial amount of refactoring. I may well
            come back to that in this PR, but it may need to wait for another PR.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: pom.xml src/main/java/hudson/scm/SubversionSCM.java src/main/java/jenkins/scm/impl/subversion/SubversionSCMSource.java src/test/java/hudson/scm/SubversionSCMUnitTest.java http://jenkins-ci.org/commit/subversion-plugin/7696afda51bf2b5cd9a835ccb5014b0eef8dca24 Log: JENKINS-26100 Change buildEnvVars to Run. NOTE: Findbugs is disabled due to the fact that there are 33 freakin' findbugs warnings that cause the whole build to error out, and fixing them is going to take a non-trivial amount of refactoring. I may well come back to that in this PR, but it may need to wait for another PR.

            Code changed in jenkins
            User: Andrew Bayer
            Path:
            src/main/java/hudson/scm/SubversionSCM.java
            src/test/java/hudson/scm/SubversionSCMUnitTest.java
            http://jenkins-ci.org/commit/subversion-plugin/0613ef35111ca2fb2e9ed5021524c6c23282e748
            Log:
            Merge pull request #182 from abayer/jenkins-26100

            JENKINS-26100 Change buildEnvVars to Run.

            Compare: https://github.com/jenkinsci/subversion-plugin/compare/1ba217661b47...0613ef35111c

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: src/main/java/hudson/scm/SubversionSCM.java src/test/java/hudson/scm/SubversionSCMUnitTest.java http://jenkins-ci.org/commit/subversion-plugin/0613ef35111ca2fb2e9ed5021524c6c23282e748 Log: Merge pull request #182 from abayer/jenkins-26100 JENKINS-26100 Change buildEnvVars to Run. Compare: https://github.com/jenkinsci/subversion-plugin/compare/1ba217661b47...0613ef35111c

            Code changed in jenkins
            User: Andrew Bayer
            Path:
            pom.xml
            src/main/java/org/jenkinsci/plugins/workflow/steps/scm/SCMStep.java
            src/test/java/org/jenkinsci/plugins/workflow/steps/scm/SCMStepTest.java
            http://jenkins-ci.org/commit/workflow-scm-step-plugin/cf36f5b5daa78f8fc4480328c5ac6ac6b4841032
            Log:
            JENKINS-26100 Return a map of SCM-contributed variables

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: pom.xml src/main/java/org/jenkinsci/plugins/workflow/steps/scm/SCMStep.java src/test/java/org/jenkinsci/plugins/workflow/steps/scm/SCMStepTest.java http://jenkins-ci.org/commit/workflow-scm-step-plugin/cf36f5b5daa78f8fc4480328c5ac6ac6b4841032 Log: JENKINS-26100 Return a map of SCM-contributed variables

            Code changed in jenkins
            User: Andrew Bayer
            Path:
            pom.xml
            src/main/java/org/jenkinsci/plugins/workflow/steps/scm/SCMStep.java
            src/main/java/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStep.java
            src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStep/config.jelly
            src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStep/help.html
            src/test/java/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStepTest.java
            http://jenkins-ci.org/commit/workflow-scm-step-plugin/bec924c64a8f19efbd7f6f08af9d879636dcf4e4
            Log:
            JENKINS-26100 Add withCheckout(scm)

            { body }

            step.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: pom.xml src/main/java/org/jenkinsci/plugins/workflow/steps/scm/SCMStep.java src/main/java/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStep.java src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStep/config.jelly src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStep/help.html src/test/java/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStepTest.java http://jenkins-ci.org/commit/workflow-scm-step-plugin/bec924c64a8f19efbd7f6f08af9d879636dcf4e4 Log: JENKINS-26100 Add withCheckout(scm) { body } step.

            Code changed in jenkins
            User: Andrew Bayer
            Path:
            pom.xml
            src/main/java/org/jenkinsci/plugins/workflow/steps/scm/SCMStep.java
            src/main/java/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStep.java
            src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStep/config.jelly
            src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStep/help.html
            src/test/java/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStepTest.java
            http://jenkins-ci.org/commit/workflow-scm-step-plugin/dbcfe52ad81d16fe3dfdc5ce642f49720aff36e3
            Log:
            Revert "JENKINS-26100 Add withCheckout(scm)

            { body }

            step."

            This reverts commit bec924c64a8f19efbd7f6f08af9d879636dcf4e4.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: pom.xml src/main/java/org/jenkinsci/plugins/workflow/steps/scm/SCMStep.java src/main/java/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStep.java src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStep/config.jelly src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStep/help.html src/test/java/org/jenkinsci/plugins/workflow/steps/scm/WithCheckoutStepTest.java http://jenkins-ci.org/commit/workflow-scm-step-plugin/dbcfe52ad81d16fe3dfdc5ce642f49720aff36e3 Log: Revert " JENKINS-26100 Add withCheckout(scm) { body } step." This reverts commit bec924c64a8f19efbd7f6f08af9d879636dcf4e4.

            Code changed in jenkins
            User: Andrew Bayer
            Path:
            pom.xml
            src/test/java/org/jenkinsci/plugins/workflow/steps/scm/SCMStepTest.java
            http://jenkins-ci.org/commit/workflow-scm-step-plugin/65952d9ba01c2d79d41d3c5c32cbc22580df1b03
            Log:
            Switch to using svn for JENKINS-26100 test so we can release.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: pom.xml src/test/java/org/jenkinsci/plugins/workflow/steps/scm/SCMStepTest.java http://jenkins-ci.org/commit/workflow-scm-step-plugin/65952d9ba01c2d79d41d3c5c32cbc22580df1b03 Log: Switch to using svn for JENKINS-26100 test so we can release.

            Code changed in jenkins
            User: Jesse Glick
            Path:
            Jenkinsfile
            pom.xml
            src/main/java/org/jenkinsci/plugins/workflow/steps/scm/SCMStep.java
            src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/GenericSCMStep/help.html
            src/test/java/org/jenkinsci/plugins/workflow/steps/scm/SCMStepTest.java
            http://jenkins-ci.org/commit/workflow-scm-step-plugin/2d2c718cb1c1b75d791c4e858571fdc9fa1b3951
            Log:
            Merge pull request #16 from abayer/jenkins-26100

            JENKINS-26100 Return a map of SCM-contributed variables

            Compare: https://github.com/jenkinsci/workflow-scm-step-plugin/compare/6b6716f56d97...2d2c718cb1c1

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: Jenkinsfile pom.xml src/main/java/org/jenkinsci/plugins/workflow/steps/scm/SCMStep.java src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/GenericSCMStep/help.html src/test/java/org/jenkinsci/plugins/workflow/steps/scm/SCMStepTest.java http://jenkins-ci.org/commit/workflow-scm-step-plugin/2d2c718cb1c1b75d791c4e858571fdc9fa1b3951 Log: Merge pull request #16 from abayer/jenkins-26100 JENKINS-26100 Return a map of SCM-contributed variables Compare: https://github.com/jenkinsci/workflow-scm-step-plugin/compare/6b6716f56d97...2d2c718cb1c1
            abayer Andrew Bayer added a comment -

            Waiting to actually resolve until https://github.com/jenkinsci/git-plugin/pull/492 is merged/released.

            abayer Andrew Bayer added a comment - Waiting to actually resolve until https://github.com/jenkinsci/git-plugin/pull/492 is merged/released.

            Code changed in jenkins
            User: Andrew Bayer
            Path:
            pom.xml
            src/main/java/hudson/plugins/git/GitSCM.java
            http://jenkins-ci.org/commit/git-plugin/47f738c54c6e8f5ead678aacfda1faa1d7433db8
            Log:
            JENKINS-26100 Switch buildEnvVars and others to Run

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: pom.xml src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/47f738c54c6e8f5ead678aacfda1faa1d7433db8 Log: JENKINS-26100 Switch buildEnvVars and others to Run

            Code changed in jenkins
            User: Mark Waite
            Path:
            pom.xml
            src/main/java/hudson/plugins/git/GitSCM.java
            http://jenkins-ci.org/commit/git-plugin/907253d7149fdd53de3389528e163be8b5e298ef
            Log:
            Merge pull request #492 from abayer/jenkins-26100

            JENKINS-26100 Switch buildEnvVars and others to Run

            Compare: https://github.com/jenkinsci/git-plugin/compare/79c66ebb8958...907253d7149f

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: pom.xml src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/907253d7149fdd53de3389528e163be8b5e298ef Log: Merge pull request #492 from abayer/jenkins-26100 JENKINS-26100 Switch buildEnvVars and others to Run Compare: https://github.com/jenkinsci/git-plugin/compare/79c66ebb8958...907253d7149f
            jglick Jesse Glick added a comment -

            I think at this point everything is merged, and only git plugin changes are still awaiting release.

            jglick Jesse Glick added a comment - I think at this point everything is merged, and only git plugin changes are still awaiting release.
            markewaite Mark Waite added a comment -

            Git plugin 3.3.1 has been released with the necessary pull request merged.

            markewaite Mark Waite added a comment - Git plugin 3.3.1 has been released with the necessary pull request merged.

            Code changed in jenkins
            User: Jesse Glick
            Path:
            src/main/java/hudson/plugins/git/GitSCM.java
            src/main/resources/hudson/plugins/git/GitSCM/buildEnv.groovy
            src/main/resources/hudson/plugins/git/GitSCM/buildEnv.properties
            http://jenkins-ci.org/commit/git-plugin/53984ad06a8d8a38cce1857e977006a0adbd3e13
            Log:
            JENKINS-26100 Supply GitSCM/buildEnv.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/hudson/plugins/git/GitSCM.java src/main/resources/hudson/plugins/git/GitSCM/buildEnv.groovy src/main/resources/hudson/plugins/git/GitSCM/buildEnv.properties http://jenkins-ci.org/commit/git-plugin/53984ad06a8d8a38cce1857e977006a0adbd3e13 Log: JENKINS-26100 Supply GitSCM/buildEnv.

            Code changed in jenkins
            User: Mark Waite
            Path:
            src/main/java/hudson/plugins/git/GitSCM.java
            src/main/resources/hudson/plugins/git/GitSCM/buildEnv.groovy
            src/main/resources/hudson/plugins/git/GitSCM/buildEnv.properties
            http://jenkins-ci.org/commit/git-plugin/2cfbf64ed55f9a23ccd576c66fa4deb83dabe91a
            Log:
            Merge pull request #508 from jglick/buildEnv

            JENKINS-26100 Supply GitSCM/buildEnv

            Compare: https://github.com/jenkinsci/git-plugin/compare/87a76efafa62...2cfbf64ed55f

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: src/main/java/hudson/plugins/git/GitSCM.java src/main/resources/hudson/plugins/git/GitSCM/buildEnv.groovy src/main/resources/hudson/plugins/git/GitSCM/buildEnv.properties http://jenkins-ci.org/commit/git-plugin/2cfbf64ed55f9a23ccd576c66fa4deb83dabe91a Log: Merge pull request #508 from jglick/buildEnv JENKINS-26100 Supply GitSCM/buildEnv Compare: https://github.com/jenkinsci/git-plugin/compare/87a76efafa62...2cfbf64ed55f

            Code changed in jenkins
            User: Jesse Glick
            Path:
            src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/GenericSCMStep/help.html
            src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/GenericSCMStep/help.jelly
            http://jenkins-ci.org/commit/workflow-scm-step-plugin/0008adc79cb5617971d5447c463d2ca1a0799e10
            Log:
            JENKINS-26100 Display buildEnv views of available SCM installations.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/GenericSCMStep/help.html src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/GenericSCMStep/help.jelly http://jenkins-ci.org/commit/workflow-scm-step-plugin/0008adc79cb5617971d5447c463d2ca1a0799e10 Log: JENKINS-26100 Display buildEnv views of available SCM installations.

            Code changed in jenkins
            User: Jesse Glick
            Path:
            src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/GenericSCMStep/help.html
            src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/GenericSCMStep/help.jelly
            http://jenkins-ci.org/commit/workflow-scm-step-plugin/9ccae57a8d5b746e10dfcdc3f44400729d7da27f
            Log:
            Merge pull request #18 from jglick/doc-JENKINS-26100

            JENKINS-26100 Display buildEnv views of available SCM installations

            Compare: https://github.com/jenkinsci/workflow-scm-step-plugin/compare/17a9946bfe3f...9ccae57a8d5b

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/GenericSCMStep/help.html src/main/resources/org/jenkinsci/plugins/workflow/steps/scm/GenericSCMStep/help.jelly http://jenkins-ci.org/commit/workflow-scm-step-plugin/9ccae57a8d5b746e10dfcdc3f44400729d7da27f Log: Merge pull request #18 from jglick/doc- JENKINS-26100 JENKINS-26100 Display buildEnv views of available SCM installations Compare: https://github.com/jenkinsci/workflow-scm-step-plugin/compare/17a9946bfe3f...9ccae57a8d5b

            Code changed in jenkins
            User: Jesse Glick
            Path:
            src/main/resources/org/jenkinsci/plugins/workflow/cps/EnvActionImpl/Binder/help.jelly
            http://jenkins-ci.org/commit/workflow-cps-plugin/1a69342650bd1846d479c296436bb8969559ca16
            Log:
            JENKINS-26100 Updating documentation.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/resources/org/jenkinsci/plugins/workflow/cps/EnvActionImpl/Binder/help.jelly http://jenkins-ci.org/commit/workflow-cps-plugin/1a69342650bd1846d479c296436bb8969559ca16 Log: JENKINS-26100 Updating documentation.

            Code changed in jenkins
            User: Jesse Glick
            Path:
            src/main/resources/org/jenkinsci/plugins/workflow/cps/EnvActionImpl/Binder/help.jelly
            http://jenkins-ci.org/commit/workflow-cps-plugin/2e9b83495d9aa91dca4479f03c35daaeb275b22f
            Log:
            Merge pull request #153 from jglick/doc-JENKINS-26100

            JENKINS-26100 Updating documentation

            Compare: https://github.com/jenkinsci/workflow-cps-plugin/compare/b78991523e2f...2e9b83495d9a

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/resources/org/jenkinsci/plugins/workflow/cps/EnvActionImpl/Binder/help.jelly http://jenkins-ci.org/commit/workflow-cps-plugin/2e9b83495d9aa91dca4479f03c35daaeb275b22f Log: Merge pull request #153 from jglick/doc- JENKINS-26100 JENKINS-26100 Updating documentation Compare: https://github.com/jenkinsci/workflow-cps-plugin/compare/b78991523e2f...2e9b83495d9a

            Code changed in jenkins
            User: Jesse Glick
            Path:
            src/main/resources/hudson/plugins/mercurial/MercurialSCM/buildEnv.groovy
            src/main/resources/hudson/plugins/mercurial/MercurialSCM/buildEnv.properties
            http://jenkins-ci.org/commit/mercurial-plugin/16fb1feb2499c01f4f44117d96691f508c00f10f
            Log:
            JENKINS-26100 Supply MercurialSCM/buildEnv.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/resources/hudson/plugins/mercurial/MercurialSCM/buildEnv.groovy src/main/resources/hudson/plugins/mercurial/MercurialSCM/buildEnv.properties http://jenkins-ci.org/commit/mercurial-plugin/16fb1feb2499c01f4f44117d96691f508c00f10f Log: JENKINS-26100 Supply MercurialSCM/buildEnv.

            Code changed in jenkins
            User: Jesse Glick
            Path:
            src/main/resources/hudson/plugins/mercurial/MercurialSCM/buildEnv.groovy
            src/main/resources/hudson/plugins/mercurial/MercurialSCM/buildEnv.properties
            http://jenkins-ci.org/commit/mercurial-plugin/8e0581ac7045aedfd2f34ea6fa01d90618df6b3c
            Log:
            Merge pull request #104 from jglick/buildEnv

            JENKINS-26100 Supply MercurialSCM/buildEnv

            Compare: https://github.com/jenkinsci/mercurial-plugin/compare/bfc7cbd995af...8e0581ac7045

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/resources/hudson/plugins/mercurial/MercurialSCM/buildEnv.groovy src/main/resources/hudson/plugins/mercurial/MercurialSCM/buildEnv.properties http://jenkins-ci.org/commit/mercurial-plugin/8e0581ac7045aedfd2f34ea6fa01d90618df6b3c Log: Merge pull request #104 from jglick/buildEnv JENKINS-26100 Supply MercurialSCM/buildEnv Compare: https://github.com/jenkinsci/mercurial-plugin/compare/bfc7cbd995af...8e0581ac7045

            So, I am a bit confused here. This ticket has been resolved but I'm not sure what combination of versions (core, plugins, etc.) are needed in order to make this work. Could someone clarify those particulars?

            leedega Kevin Phillips added a comment - So, I am a bit confused here. This ticket has been resolved but I'm not sure what combination of versions (core, plugins, etc.) are needed in order to make this work. Could someone clarify those particulars?
            markewaite Mark Waite added a comment -

            Git plugin 3.4.1 includes the necessary change, though JENKINS-45489 shows that some of the entries in the returned map seem to include incorrect data. JENKINS-45489 includes more details of the testing and could also be used as an example of how to read the information.

            I don't know the versions of the other SCM plugins which have that capability.

            markewaite Mark Waite added a comment - Git plugin 3.4.1 includes the necessary change, though JENKINS-45489 shows that some of the entries in the returned map seem to include incorrect data. JENKINS-45489 includes more details of the testing and could also be used as an example of how to read the information. I don't know the versions of the other SCM plugins which have that capability.

            Hmmm - I have Git plugin v3.4.1 installed, but the following snippet of code returns 'null'. Am I doing something wrong?

             

            node {
                def retval = checkout (changelog: true, poll: true, scm: [$class: 'GitSCM', ... other params for the git checkout])
                echo retval.toString()   // <--- prints 'null'
            }
            
            leedega Kevin Phillips added a comment - Hmmm - I have Git plugin v3.4.1 installed, but the following snippet of code returns 'null'. Am I doing something wrong?   node {     def retval = checkout (changelog: true , poll: true , scm: [$class: 'GitSCM' , ... other params for the git checkout])     echo retval.toString()   // <--- prints ' null ' }
            markewaite Mark Waite added a comment -

            I don't know how groovy .toString() of a map behaves. The retval is a map. You can see an example of the check I'm running in my test pipeline, if that helps

            markewaite Mark Waite added a comment - I don't know how groovy .toString() of a map behaves. The retval is a map. You can see an example of the check I'm running in my test pipeline, if that helps

            Yeah, that's why I asked. It looks like my snippet from above should work but it doesn't so something on my system must need to be updated or something. I'd like to know which bits I'm missing to make it work.

            Just to be clear, the return value from checkout() is actually null on my system, so it has nothing to do with the toString() method. Here's a variation to illustrate:

             

            node {
                def retval = checkout (...)
                if (retval == null) echo "Undefined"
            }

            This snippet prints out "Undefined" in the log.

            leedega Kevin Phillips added a comment - Yeah, that's why I asked. It looks like my snippet from above should work but it doesn't so something on my system must need to be updated or something. I'd like to know which bits I'm missing to make it work. Just to be clear, the return value from checkout() is actually null on my system, so it has nothing to do with the toString() method. Here's a variation to illustrate:   node { def retval = checkout (...) if (retval == null ) echo "Undefined" } This snippet prints out "Undefined" in the log.
            romanp Roman Pickl added a comment -

            just wanted to add that

            GIT_REV=checkout(scm).GIT_COMMIT

            works for us when run as part of a declarative pipeline within script{}

            romanp Roman Pickl added a comment - just wanted to add that GIT_REV=checkout(scm).GIT_COMMIT works for us when run as part of a declarative pipeline within script{}
            markewaite Mark Waite added a comment -

            leedega, my working sample is using scripted pipeline. Since romanp's working sample is using declarative, I'm confident it works in both cases with the latest plugin versions.

            I run my tests using the plugin versions stored in my lts-with-plugins repository. If you'd like to compare versions, you could clone that repository (you'll need git lfs, since it is LFS enabled).

            markewaite Mark Waite added a comment - leedega , my working sample is using scripted pipeline. Since romanp 's working sample is using declarative, I'm confident it works in both cases with the latest plugin versions. I run my tests using the plugin versions stored in my lts-with-plugins repository . If you'd like to compare versions, you could clone that repository (you'll need git lfs, since it is LFS enabled).

            markewaite romanp What version of the jenkins core are you both using? I'm currently on LTS v2.46.3. Maybe there is some feature in a newer core version that is required to make this work as well.

            leedega Kevin Phillips added a comment - markewaite romanp  What version of the jenkins core are you both using? I'm currently on LTS v2.46.3. Maybe there is some feature in a newer core version that is required to make this work as well.
            markewaite Mark Waite added a comment -

            I doubt the differences between Jenkins 2.46.3 (the prior LTS) and 2.60.2 (the current LTS and the version I'm using) are enough to matter here. Have you checked your plugins for upgrades?

            markewaite Mark Waite added a comment - I doubt the differences between Jenkins 2.46.3 (the prior LTS) and 2.60.2 (the current LTS and the version I'm using) are enough to matter here. Have you checked your plugins for upgrades?

            Yes, I updated the Git plugin and all pipeline* plugins to the latest version yesterday to try and get this working. This is what prompted me to post my original question. I can try upgrading the Jenkins core on one of my sandboxes just to see if that makes any difference just in case.

            leedega Kevin Phillips added a comment - Yes, I updated the Git plugin and all pipeline* plugins to the latest version yesterday to try and get this working. This is what prompted me to post my original question. I can try upgrading the Jenkins core on one of my sandboxes just to see if that makes any difference just in case.
            jglick Jesse Glick added a comment -

            You need Jenkins core 2.60 or later. Messaging has been added to the checkout step’s inline help already.

            jglick Jesse Glick added a comment - You need Jenkins core 2.60 or later. Messaging has been added to the checkout step’s inline help already.
            romanp Roman Pickl added a comment -

            we are running Jenkins ver. 2.60.2

            romanp Roman Pickl added a comment - we are running Jenkins ver. 2.60.2

            With above changes, will it be possible to get the Environment list in the following way,

            <snip>

            Run run;

            EnvVars env = run.getEnvironment(listener);

            env.get("GIT_URL");

            </snip>

             

            hariharan Hariharan Kuppusamy added a comment - With above changes, will it be possible to get the Environment list in the following way, <snip> Run run; EnvVars env = run.getEnvironment(listener); env.get("GIT_URL"); </snip>  
            markewaite Mark Waite added a comment -

            hariharan The environment variables are returned by the pipeline checkout command as a map

            def map_of_checkout_vars = checkout([$class: 'GitSCM'])
            

            Refer to my Jenkinsfile for an example using those variables.

            markewaite Mark Waite added a comment - hariharan The environment variables are returned by the pipeline checkout command as a map def map_of_checkout_vars = checkout([$class: 'GitSCM']) Refer to my Jenkinsfile for an example using those variables.
            slapersonne Simon La Personne added a comment - - edited

            Hello,

            I have the same issue than leedega, with Jenkins 2.60.2 and Git plugin 3.5.0 : checkout command does not return anything.

            Is an other plugin needed to recover and process these variables ?

            slapersonne Simon La Personne added a comment - - edited Hello, I have the same issue than leedega , with Jenkins 2.60.2 and Git plugin 3.5.0 : checkout command does not return anything. Is an other plugin needed to recover and process these variables ?
            markewaite Mark Waite added a comment -

            slapersonne I'm using Jenkins 2.60.2 with the plugins listed in my lts-with-plugin repository. You could compare your plugin list to those plugins to detect differences.

            markewaite Mark Waite added a comment - slapersonne I'm using Jenkins 2.60.2 with the plugins listed in my lts-with-plugin repository . You could compare your plugin list to those plugins to detect differences.
            jglick Jesse Glick added a comment - - edited

            You need to update workflow-scm-step.

            jglick Jesse Glick added a comment - - edited You need to update workflow-scm-step .

            Thank you for your answers, with workflow-scm-step updated to 2.6 the variables can well be recovered within the map.

            slapersonne Simon La Personne added a comment - Thank you for your answers, with workflow-scm-step updated to 2.6 the variables can well be recovered within the map.

            jglick

            Hello, I had this support ticket https://support.cloudbees.com/hc/en-us/requests/47538 marked as resolved based on the work done to resolve this issue. My request was for pipeline to support GHPRB style "skip build phrase". Forgive me but it's not obvious how I would leverage the fix for this issue to give me the "skip build phrase" type functionality. Could you give some pointers on that?

            Thanks

            rainwaj Justin Rainwater added a comment - jglick Hello, I had this support ticket  https://support.cloudbees.com/hc/en-us/requests/47538  marked as resolved based on the work done to resolve this issue. My request was for pipeline to support GHPRB style "skip build phrase". Forgive me but it's not obvious how I would leverage the fix for this issue to give me the "skip build phrase" type functionality. Could you give some pointers on that? Thanks
            markewaite Mark Waite added a comment -

            rainwaj I assume they were thinking that one or more of the values in the map returned from the pipeline checkout() step could be used inside your pipeline script. The names include the GIT_COMMIT, GIT_AUTHOR, and GIT_AUTHOR, and the associated values come from the most recent commit on that branch.

            I think they intended that you would use those values to decide if the pipeline should finish early, rather than continuing through to the end of the pipeline.

            markewaite Mark Waite added a comment - rainwaj I assume they were thinking that one or more of the values in the map returned from the pipeline checkout() step could be used inside your pipeline script. The names include the GIT_COMMIT, GIT_AUTHOR, and GIT_AUTHOR, and the associated values come from the most recent commit on that branch. I think they intended that you would use those values to decide if the pipeline should finish early, rather than continuing through to the end of the pipeline.

            Thanks for the reply markewaite. Do you happen to know if checkout() is also returning the PR title/description and/or comments? I think that's the only way this new functionality could provide the same value as "Skip Build Phrase" from GHPRB.

            rainwaj Justin Rainwater added a comment - Thanks for the reply markewaite . Do you happen to know if checkout() is also returning the PR title/description and/or comments? I think that's the only way this new functionality could provide the same value as "Skip Build Phrase" from GHPRB.
            markewaite Mark Waite added a comment -

            rainwaj I know that it is not returning any pull request specific information (at least not at this time). It returns information about the commit and its branch, not about the pull request.

            markewaite Mark Waite added a comment - rainwaj I know that it is not returning any pull request specific information (at least not at this time). It returns information about the commit and its branch, not about the pull request.
            gotson Gauthier R. added a comment -

            Hello, i asked a question on StackOverflow, i am using JGit and cannot get any information from scm checkout using the latest version of the plugin.

            Would you know if this is a limitation of JGit itself, or from the SCM steps plugin ?

            gotson Gauthier R. added a comment - Hello, i asked a question on StackOverflow , i am using JGit and cannot get any information from scm checkout using the latest version of the plugin. Would you know if this is a limitation of JGit itself, or from the SCM steps plugin ?
            markewaite Mark Waite added a comment -

            gotson in your stackoverflow question, you mention that you're running git plugin 3.3.0. The fix was not included in the git plugin until 3.3.2. You'll need to update to at least git plugin 3.3.2.

            markewaite Mark Waite added a comment - gotson in your stackoverflow question, you mention that you're running git plugin 3.3.0. The fix was not included in the git plugin until 3.3.2. You'll need to update to at least git plugin 3.3.2.
            gotson Gauthier R. added a comment -

            markewaite thanks a lot for your help, upgrading the Git Plugin to 3.3.2 indeed solved my problem !

            gotson Gauthier R. added a comment - markewaite thanks a lot for your help, upgrading the Git Plugin to 3.3.2 indeed solved my problem !
            nolange79 Norbert Lange added a comment -

            I might be dense, but I still dont understand how I would do this with a declarative pipeline (without script blocks).
            Any help here?

            withCheckout is nowhere to be found

            the env variables are not set by default:

            pipeline {
                agent none
                stages {
                    stage('checkout') {
                        post { always { deleteDir() } }
                        agent any
                        steps {
                            checkout([$class: 'GitSCM', 
                                userRemoteConfigs: [[url: 'https://github.com/docker/for-linux.git']]])
                            sh 'set'
                        }
                    }
                }
            }
            

            trying to stuff into a withEnv block fails with `java.lang.UnsupportedOperationException: must specify $class with an implementation of interface java.util.List`

            pipeline {
                agent none
                stages {
                    stage('checkout') {
                        post { always { deleteDir() } }
                        agent any
                        steps {
                            withEnv(checkout([$class: 'GitSCM', 
                                userRemoteConfigs: [[url: 'https://github.com/docker/for-linux.git']]])) {
                                    sh 'set'  
                                }
                        }
                    }
                }
            }
            

            Jenkins ver. 2.219 (docker alpine installation)
            git 4.1.1 true
            git-client 3.1.1 true
            workflow-scm-step 2.10 true

            nolange79 Norbert Lange added a comment - I might be dense, but I still dont understand how I would do this with a declarative pipeline (without script blocks). Any help here? withCheckout is nowhere to be found the env variables are not set by default: pipeline { agent none stages { stage( 'checkout' ) { post { always { deleteDir() } } agent any steps { checkout([$class: 'GitSCM' , userRemoteConfigs: [[url: 'https: //github.com/docker/ for -linux.git' ]]]) sh 'set' } } } } trying to stuff into a withEnv block fails with `java.lang.UnsupportedOperationException: must specify $class with an implementation of interface java.util.List` pipeline { agent none stages { stage( 'checkout' ) { post { always { deleteDir() } } agent any steps { withEnv(checkout([$class: 'GitSCM' , userRemoteConfigs: [[url: 'https: //github.com/docker/ for -linux.git' ]]])) { sh 'set' } } } } } Jenkins ver. 2.219 (docker alpine installation) git 4.1.1 true git-client 3.1.1 true workflow-scm-step 2.10 true
            markewaite Mark Waite added a comment -

            nolange79 could you review the Jenkins Minute video "Using Git Environment Variables" and see if it resolves your issue?

            If it resolves your issue, then I'll add a git plugin documentation section on using the git plugin with Pipeline and will embed that video in the new section.

            markewaite Mark Waite added a comment - nolange79 could you review the Jenkins Minute video " Using Git Environment Variables " and see if it resolves your issue? If it resolves your issue, then I'll add a git plugin documentation section on using the git plugin with Pipeline and will embed that video in the new section.
            nolange79 Norbert Lange added a comment -

            markewaite: No, video is generally a bad idea, and that specific one is not helping at all.

            Here is the problem in a single paragraph:

            checkout()
            // returns ""
            sh 'echo ${GIT_COMMIT}'
            // returns "null"
            echo "${env.GIT_COMMIT}"
            

            No environment variables are set.

            nolange79 Norbert Lange added a comment - markewaite : No, video is generally a bad idea, and that specific one is not helping at all. Here is the problem in a single paragraph: checkout() // returns "" sh 'echo ${GIT_COMMIT}' // returns " null " echo "${env.GIT_COMMIT}" No environment variables are set.
            markewaite Mark Waite added a comment -

            nolange79 it looks to me like you're using declarative pipeline but then ignoring the default checkout which declarative pipeline provides for you, without explicitly stating that you intend to skip the default checkout. If you intend to skip the default checkout then you should extend your declarative pipeline with

            options {
                skipDefaultCheckout()
            }
            

            If you don't intend to skip the default checkout, then the techniques described in that video will work.

            If you intend to skip the default checkout, specify your own checkout, and use the return value from the checkout step to collect the settings used in the checkout, then it appears you'll need to use a script block in your declarative Pipeline. Refer to this example that I created while experimenting with the question. The example skips the default checkout, performs its own checkout, and assigns the return value of checkout() to the variable results. It then displays values from results.

            markewaite Mark Waite added a comment - nolange79 it looks to me like you're using declarative pipeline but then ignoring the default checkout which declarative pipeline provides for you, without explicitly stating that you intend to skip the default checkout. If you intend to skip the default checkout then you should extend your declarative pipeline with options { skipDefaultCheckout() } If you don't intend to skip the default checkout, then the techniques described in that video will work. If you intend to skip the default checkout, specify your own checkout, and use the return value from the checkout step to collect the settings used in the checkout, then it appears you'll need to use a script block in your declarative Pipeline. Refer to this example that I created while experimenting with the question. The example skips the default checkout, performs its own checkout, and assigns the return value of checkout() to the variable results . It then displays values from results .
            markewaite Mark Waite added a comment -

            nolange79 also, since this bug report is about the git step and not the checkout step, it would be better to use a different location for your question and for the answer to your question. When you ask a question in an issue, you limit the number of people that will answer the question to only those that are monitoring that bug. A question asked in the Jenkins mailing lists or the Jenkins chat channels can be seen by a much larger group.

            markewaite Mark Waite added a comment - nolange79 also, since this bug report is about the git step and not the checkout step, it would be better to use a different location for your question and for the answer to your question. When you ask a question in an issue, you limit the number of people that will answer the question to only those that are monitoring that bug. A question asked in the Jenkins mailing lists or the Jenkins chat channels can be seen by a much larger group.
            nolange79 Norbert Lange added a comment - - edited

            Yeah, I posted the entire declarative pipeline couple posts before.

            I managed to get the variables with a script block, but I expected that there would be a way to get to this without breaking into scripting mode.

            What is a default checkout: where would the pipeline know the url from?
            Does withCheckout exist? its referenced in this thread.
            Would be nice to get withEnv working like I illustrated above.

            Docs send you completely in the wrong direction unfortunately.

            Edit: I replied here because this is often referenced as "answer"

            nolange79 Norbert Lange added a comment - - edited Yeah, I posted the entire declarative pipeline couple posts before. I managed to get the variables with a script block, but I expected that there would be a way to get to this without breaking into scripting mode. What is a default checkout: where would the pipeline know the url from? Does withCheckout exist? its referenced in this thread. Would be nice to get withEnv working like I illustrated above. Docs send you completely in the wrong direction unfortunately. Edit: I replied here because this is often referenced as "answer"
            markewaite Mark Waite added a comment - - edited

            I managed to get the variables with a script block, but I expected that there would be a way to get to this without breaking into scripting mode.

            The variables are available if you don't use the checkout step in the declarative pipeline. The declarative pipeline has an implicit checkout step that happens before the Pipeline executes.

            What is a default checkout: where would the pipeline know the url from?

            When the Jenkinsfile for the Pipeline is read from SCM, the declarative pipeline uses that URL.

            Does withCheckout exist? its referenced in this thread.

            No, withCheckout does not exist. It was added to the scm step plugin May 5, 2017 and then removed on May 16, 2017.

            Docs send you completely in the wrong direction unfortunately.

            Which docs send you in the wrong direction?

            markewaite Mark Waite added a comment - - edited I managed to get the variables with a script block, but I expected that there would be a way to get to this without breaking into scripting mode. The variables are available if you don't use the checkout step in the declarative pipeline. The declarative pipeline has an implicit checkout step that happens before the Pipeline executes. What is a default checkout: where would the pipeline know the url from? When the Jenkinsfile for the Pipeline is read from SCM, the declarative pipeline uses that URL. Does withCheckout exist? its referenced in this thread. No, withCheckout does not exist. It was added to the scm step plugin May 5, 2017 and then removed on May 16, 2017 . Docs send you completely in the wrong direction unfortunately. Which docs send you in the wrong direction?
            nolange79 Norbert Lange added a comment -

            "Which docs send you in the wrong direction?"

            Plain Pipelines using "inline Jenkinsfiles" seem to be largely ignored from all docs, similarly you often need to checkout multiple sources. If this is not explicitly mentioned, one would assume it works the same.
            The step returns a map of env variables already, so pushing those into withEnv would be a natural fit.

            That there is no "declarative" way to do this, is weird. I had many Problems with scripted pipelines, particularly when it comes to error handling (storing artifacts will silently fail, then cause an error at the end of the pipeline?) that I would want to stay clear of those.

            nolange79 Norbert Lange added a comment - "Which docs send you in the wrong direction?" Plain Pipelines using "inline Jenkinsfiles" seem to be largely ignored from all docs, similarly you often need to checkout multiple sources. If this is not explicitly mentioned, one would assume it works the same. The step returns a map of env variables already, so pushing those into withEnv would be a natural fit. That there is no "declarative" way to do this, is weird. I had many Problems with scripted pipelines, particularly when it comes to error handling (storing artifacts will silently fail, then cause an error at the end of the pipeline?) that I would want to stay clear of those.
            markewaite Mark Waite added a comment -

            Thanks

            markewaite Mark Waite added a comment - Thanks

            People

              abayer Andrew Bayer
              jglick Jesse Glick
              Votes:
              85 Vote for this issue
              Watchers:
              100 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: