Details
-
Improvement
-
Status: Resolved (View Workflow)
-
Minor
-
Resolution: Won't Fix
-
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
- is related to
-
-
- Resolved
-
- relates to
-
JENKINS-37227 Metastep support for checkout step
-
- Open
-
Activity
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?
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 calling `checkout scm: [$class: 'GitSCM',` is the normal case? I don't understand why that would be desirable when using git in a pipeline.
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.