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

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

    XMLWordPrintable

Details

    • Improvement
    • Status: Resolved (View Workflow)
    • Minor
    • Resolution: Won't Fix
    • pipeline
    • None

    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

            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 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.
            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.

            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.

            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?

            restjohn 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?
            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 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.
            seglo 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.

            seglo 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.
            jglick Jesse Glick added a comment -

            See the linked issue.

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

            People

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

              Dates

                Created:
                Updated:
                Resolved: