Q: Migrate git-init to script mode?

[imjasonh]

The git-init image, used to support git-type PipelineResources, invokes a Go binary that drives git CLI invocations to clone a repo.

One of the main benefits of git-init was that it made it easy to chain together multiple CLI invocations inside one step, and being Go made it easy to have control flow logic.

However, being a Go binary that wraps the git CLI adds a layer of indirection to users interested in understanding/debugging/extending it, since they have to go through the Go code to change its behavior.

Now that we have script mode, git-type PipelineResources could simply prepend a step that defines a script: to do all the things git-init does (i.e., git init, git remote add origin <repo>, git fetch origin <revision>, etc.), removing the indirection. Users could modify the step to add more logging, without having to rebuild the image. The image could simply be the base image we already use for git-init to ensure git is installed, or an image like alpine:git.

The disadvantage of this is that git-type PipelineResources become dependent on (presumably) Bash scripts, which can grow to unmaintainable sizes. Unit testing is hard in Bash, but git-init has no unit tests today anyway.

What do people think about modifying the git-type PipelineResource in this way?

/kind question

[imjasonh]

As a concrete example, modify GetInputTaskModifier in git_resource.go to something like this gist.

[ghost]

I'm in favor of using script mode. Could we just have it live as a task in the catalog instead of committing changes to the pipeline resource?

[vdemeester]

As @sbwsg said 👼 I'll update my PR with workspace support and using script mode instead 👼 😉

[chmouel]

Can't be more happy to have one image less to support 👍

@sbwsg about having it in the catalog, we would need to refer it somehow in release.yaml isnt it ?

[ghost]

we would need to refer it somehow in release.yaml isnt it ?

Ahh I hadn't thought of this. We'd want this to be like a default-installed task that comes along with the tekton controller I expect.

[bobcatfish]

@sbwsg I think you mentioned you were working on updating the existing git Task in the catalog - would it make sense to assign this to you?

[vdemeester]

@bobcatfish work is happening here : tektoncd/catalog#188

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.