How can Go use a release tag as pipeline materials?

[Zhaohui Wei]

This is critical to us because we would like to run Go pipelines to perform product release processes. Thanks.

[Fredrik Wendt]

Why don't you put all tags in one source repository? Make every commit (or changeset) a release tag, and have pipelines trigger on that.

What are you missing - what would you like to see? What is it that you can't model with Go today? What have you tried, what are your alternatives?

/ Fredrik

2016-03-01 18:00 GMT+01:00 Zhaohui Wei <july...@gmail.com>:

This is critical to us because we would like to run Go pipelines to perform product release processes. Thanks.

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

+46 702 778511

[Zhaohui Wei]

I am not sure if I understand your questions. Of course tags are snapshots of code changes within a source repo, and a commit can also be looked as a snapshot of source in the github repo.

My question is, most of times we define a branch in Materials branch, but we would like to know how we can define a release tag in Materials branch.

[Fredrik Wendt]

Well, it's perfectly possible to put one file, a plain text file, called "releases" in it's own source code repository, and it contains nothing but:

repoA:1234567890abcdef:v1.2.3

repoA:34567890abcdef12:v1.2.2

It points out some recorded information about what changeset/commit in a repository was called something, for marketing reasons. Every change to that repository will emit an artifact with a changeset an version number for other pipelines to pick up and use as input.

Another option is to create all the pipelines dynamically:

create a SetupPipelines pipeline that looks for your tags, and when found, creates new pipelines automatically/programmatically using the GoCD APIs. https://api.go.cd/current/#create-pipeline

A third option is to simply have a first stage that verifies that whatever change appears in the source code repository is in fact a tag. If it's not, the job "fails" and stops any following stages.

A fourth option is to have two repositories:

* a Main repository where humans push source code and tags to. This repository is monitored by a Pipeline that only does one thing: it looks at all incoming changesets, and if one of those contains a release tag, it will push that changeset (and all upstream changesets in the graph) from the Main repository to the Release repository.

* a Release repository is where pushes are made automatically, triggered by the above job when a new tag is found in the Main repository. Your release pipelines/jobs watch this Release repository and is only run/triggered when a push (with a new tag) has been made to this Release repository.

I'm sure there are more patterns and solutions.

/ Fredrik

[Zhaohui Wei]

Thanks Fredrik for providing solutions. I have more than a hundred of projects and each project has its own Github repo, so I think the best and simple way is use trigger with options.