Pipeline: migrate the pullrequest-init code to go-scm to handle multiple git providers?

[jstrachan]

It would be great to migrate the pullrequest-init code to support any git provider (bitbucket, gitlab, gitea et al). e.g. for https://github.com/tektoncd/pipeline/issues/1000

We've been using this fork of go-scm to handle multiple git providers via a single unified API: https://github.com/jenkins-x/go-scm and its been working great.

e.g. we've ported the main prow ChatOps commands into a new webhook handle using it: https://github.com/jenkins-x/lighthouse/ and its working great for many git providers.

Its a small simple library with modest dependencies so is a drop in replacement for the https://github.com/google/go-github library which would then solve the multi-git provider support issue.

The generated JSON is close to the current JSON (a few minor changes though) but at least uses the same JSON schema whatever git provider is used.

e.g. here's some examples

• Pull Request
• PR Comments

To create the scm.Client we just need 3 strings; the driver name, optional server URL and oauth token...

// for github
client, err := factory.NewClient("github", "", oauthToken)

// some gitlab server
client, err := factory.NewClient("gitlab", "https://foo.com/bar", oauthToken)

How do folks think about migrating to this go-scm library?

[dlorenc]

cc @wlynch @bobcatfish

[wlynch]

Thanks for raising this!

I'm not against sharing the common type here, but we'll probably need to make some changes to support everything we want.

The biggest concern I see is the lack of a common status enum, since it means pipelines will need to know the implementation specific statuses. For example:

| GitHub Status | GitHub Check Run | GitLab |
| -|-|-|
| success | success | success |
| failure | failed | failed |
| pending | queued | pending
| error | action_required | |
| | in_progess | running |
| | canceled | canceled |
| | neutral |
| | timed_out | |

@jstrachan few questions:

1. What's the feature diff between jenkins-x/go-scm and drone/go-scm? What was missing in the original library? Anything blocking upstreaming the changes?
2. AFAICT, there doesn't appear to be support for PR status updates? Am I reading this right or am I not looking in the right place? :upside_down_face:

[dlorenc]

Looks like we also need support for labels in go-scm.

[kav]

Any update here? Happy to contribute where needed. Would really love to use Tekton to manage Bitbucket PRs. Is the next step adding BB PR labels to the jenkins-x go-scm fork?

[wlynch]

@kav Yes! That would be very helpful. https://github.com/jenkins-x/go-scm/issues/21

[wlynch]

I'll be starting work to replatform the PullRequest resource on go-scm soon. I'm sure a bunch of missing bits will shake out as a result :upside_down_face:

[Timoses]

I really like the approach by Concourse CI to make "Resources" a container which handles 'get', 'put' and 'check' requests. It renders resources very modular, as anybody can write up a new image and use it as a resource.

Was there any consideration using a similar approach with TektonCD Resources? It would allow the community to create "resource containers" themselves and prevent in-tree implementations to support all the varieties (e.g. "I want Gitea support!" -> " Write your own resource container").