Git push at the end without run pipeline again

[Kadu Barral]

Hello,

I would like to now if gocd can add, commit and push to same repository that I'm using as material without run pipeline again.

My use case is that I have one repo for application and other repo with k8s manifests and dockerfiles.

pipeA = build golang app

pipeB = build docker and update image tag (kustomize)

I would like to call also pipeB if I do some change in dockerfile for example.

repoA -> pipeA -> pipeB

         repoB ---/

This is probably the wrong way, but at the end of pipeB I'm running git commands

git add develop && git commit -m "update image" && git push

So, the question is:

- The same way as docker images are pushed to repo, there is a way to update the material without run implicit git commands? If yes, how can I configure commit message and files that I want to add?

- Is it possible to not run the same pipeline again because the this specific push?

Thank you

[Kadu Barral]

Still stuck at this. any advice guys?

[Sriram Narayanan]

While there is a whitelisting/blacklisting of material paths, could you explain a bit on what you are trying to achieve here?

My suggestion:

Since the golang app, it's container image and it's Kustomize file are all related, you may want to consider:

- creating these in consecutive stages within the same pipeline, 

- artifact the kustomize file (and also push it and any metadata info in a text file to a "deployment artifacts" git repo)

- refer to the kustomize file as an artifact from downstream pipelines (especially useful when you use GoCD's Trigger with Options (the play+ button)).

This way:

- All the operations are atomic and together

- if a container creation fails, then the kustomize file (the next stage) isn't triggered

- you can use the kustomize file in all downstream pipelines (especially if you want to spin up an environment on demand)

- over time as your pipelines become richer and are more evolved, you'll benefit from the forward and reverse traceability of knowing (e.g. by comparing two versions of a pipeline that generated the kustomize file and the container, you can find the delta of the various input materials that went into the container).

- you could point people to the "deployment artifacts" git repo and they can review the metadata file (like a readme file, for e.g.) and use that particular version of the kustomize file for their deployments. This is only useful for those who won't be deploying via downstream pipelines - like customers, for e.g.

- Those users who need to reference only the kustomize file as a material for their own automated deployments, for e.g., can now have a deployment artifacts repo to refer to.

-- Ram

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/0c1d47f6-94e3-4d7c-9be1-d2acad778055n%40googlegroups.com.