I saw related discussions on gocd community. and you guys were wondering why we need git tags support.
It seems this problem is not solved, and I am also need support for git tags, the reason is that, we want to do deployment with new released version.
Everytime a new release created, we want to deploy it (our products environement) or to integrate it to other projects (dependencies)
yqian1991
All 4 comments
Sounds like a good candidate for a material plugin. This is not going to be part of the core, since it is quite a niche use case. Not that it is wrong, but quite niche in my opinion.
You can take a look at the source code of other material (SCM) plugins to see how they work.
I'm closing this issue for now. Let me know if you think it should be reopened for some reason.
Cheers,
Aravind
arvindsv
on 6 Jul 2015
I'd like to second the initial request.
It appears to me that the effort must be disproportionate to just implementing it as a part of Go's native Git support: It is already possible to specify the branch to pull from. Extending this to arbitrary revisions does look far easier than duplicating the whole Git material source.
This is also the way it's implemented by other tools like Jenkins.
F30
on 19 Sep 2016
Yeah....saying "git tags are niche" is a pretty arbitrary hill to stand on. Tagging is pretty standard practice, in fact I see 24 public tags on the gocd project it's self! (https://github.com/gocd/gocd/tags)
Checking out a tag vs checking about branch shouldn't be a huge code change. @arvindsv
thenoid
on 3 Oct 2019
Seconded. Here is out use case. We depend on some open source components on some builds. The best way to integrate these into the pipeline is to use a Git report as a material source. But we want to pin those components to known versions. At the moment the only choice is to use a branch associated with the release we want to use, but that branch may evolve, introducing instability.
eliaslevy
on 5 Mar 2020
Related issues
dwijnand
路
7Comments
GaneshSPatil
路
3Comments
bzcpla
路
3Comments
GaneshSPatil
路
3Comments
chriswhelix
路
5Comments
Most helpful comment
Seconded. Here is out use case. We depend on some open source components on some builds. The best way to integrate these into the pipeline is to use a Git report as a material source. But we want to pin those components to known versions. At the moment the only choice is to use a branch associated with the release we want to use, but that branch may evolve, introducing instability.