• Icon: Improvement Improvement
    • Resolution: Won't Fix
    • Icon: Minor Minor
    • pipeline
    • None

      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?

          [JENKINS-27018] Provide either 'branch' or 'tag' in git step

          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.

          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.

          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.

          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.

          I whole-heartedly agree with seglo'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?

          Robert St. John added a comment - I whole-heartedly agree with seglo '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?

          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.

          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.

          Sean Glover added a comment -

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

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

          Jesse Glick added a comment -

          See the linked issue.

          Jesse Glick added a comment - See the linked issue.

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

              Created:
              Updated:
              Resolved: