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

Provide either 'branch' or 'tag' in git step

    Details

    • Type: Improvement
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Won't Fix
    • Component/s: pipeline
    • Labels:
      None
    • Similar Issues:

      Description

      Hi,

      the 'git' step is one of the most important steps implemented for workflow.

      However, there are many cases where I need to checkout the particular git tag, instead of the branch.

      currently I have to do something like:

      checkout scm: [$class: 'GitSCM', 
            userRemoteConfigs: [[url: 'git@github.com:MYCOMPANY/cd-workflow.git']], 
            branches: [[name: 'refs/tags/workflow-1.0']]], changelog: false, poll: false
      

      the main reason is I want to keep versioned workflow scripts on my repo and load a specific version of it. But I have also several other use cases when I need a tag from the git repository.

      The notation above is actually too long and overcomplicated. Instead, I would expect to use the code like:

      git url: 'git@github.com:MYCOMPANY/cd-workflow.git', tag: 'workflow-1.0', changelog: false, poll: false
      

      which is much shorter and similar to a typical git usage.

      By other words, the step might support either 'branch' or 'tag' parameter. In some rare cases it would be nice also to have possibility to checkout a particular commit.

      Would it be possible to add such a feature?

        Attachments

          Issue Links

            Activity

            ykryshchuk Yuriy Kryshchuk created issue -
            Hide
            jglick Jesse Glick added a comment -

            The git step is intended to just cover the most common cases with a highly simplified syntax. Building a tag is probably out of scope. Use the checkout step with GitSCM for all uses cases it does not cover.

            Show
            jglick Jesse Glick added a comment - The git step is intended to just cover the most common cases with a highly simplified syntax. Building a tag is probably out of scope. Use the checkout step with GitSCM for all uses cases it does not cover.
            jglick Jesse Glick made changes -
            Field Original Value New Value
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Won't Fix [ 2 ]
            jglick Jesse Glick made changes -
            Link This issue is related to JENKINS-26100 [ JENKINS-26100 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 161209 ] JNJira + In-Review [ 196683 ]
            abayer Andrew Bayer made changes -
            Component/s pipeline-general [ 21692 ]
            abayer Andrew Bayer made changes -
            Component/s workflow-plugin [ 18820 ]
            Hide
            seglo Sean Glover added a comment - - edited

            I really dislike answers like these. Who is to say what is the most common case and what is not. Any project of some order of complexity is going to have to deviate from what's considered a common case and I don't think the solution to these types of problems is user friendly. the `[$class` syntax is powerful, but awfully hard to read and learn about (parameters, types, etc). For pipeline commands that have an alias there should be a better way to passing additional "advanced" configuration in some generalized way i.e. `git extra-params: {some collection of key value pairs}`. Just my 2 cents.

            Show
            seglo Sean Glover added a comment - - edited I really dislike answers like these. Who is to say what is the most common case and what is not. Any project of some order of complexity is going to have to deviate from what's considered a common case and I don't think the solution to these types of problems is user friendly. the `[$class` syntax is powerful, but awfully hard to read and learn about (parameters, types, etc). For pipeline commands that have an alias there should be a better way to passing additional "advanced" configuration in some generalized way i.e. `git extra-params: {some collection of key value pairs}`. Just my 2 cents.
            Hide
            restjohn Robert St. John added a comment -

            I whole-heartedly agree with Sean Glover's comment. What's the point of all this nice DSL syntax if one needs to resort immediately to a workaround syntax for what I'd argue is in fact a pretty common use case?

            Show
            restjohn Robert St. John added a comment - I whole-heartedly agree with Sean Glover 's comment. What's the point of all this nice DSL syntax if one needs to resort immediately to a workaround syntax for what I'd argue is in fact a pretty common use case?
            Hide
            jglick Jesse Glick added a comment -

            Direct use of GitSCM is the normal case. The git step was introduced as part of the Workflow 1.0 prototype so it is too late to delete it, but it can be deprecated / migrated as soon as JENKINS-37227 allow that to happen with pretty symbols.

            Show
            jglick Jesse Glick added a comment - Direct use of GitSCM is the normal case. The git step was introduced as part of the Workflow 1.0 prototype so it is too late to delete it, but it can be deprecated / migrated as soon as JENKINS-37227 allow that to happen with pretty symbols.
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-37227 [ JENKINS-37227 ]
            Hide
            seglo Sean Glover added a comment -

            Jesse Glick calling `checkout scm: [$class: 'GitSCM',` is the normal case? I don't understand why that would be desirable when using git in a pipeline.

            Show
            seglo Sean Glover added a comment - Jesse Glick calling `checkout scm: [$class: 'GitSCM',` is the normal case? I don't understand why that would be desirable when using git in a pipeline.
            Hide
            jglick Jesse Glick added a comment -

            See the linked issue.

            Show
            jglick Jesse Glick added a comment - See the linked issue.

              People

              • Assignee:
                jglick Jesse Glick
                Reporter:
                ykryshchuk Yuriy Kryshchuk
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: