tkn pac UX redesign

[sm43]

https://github.com/openshift-pipelines/pipelines-as-code/pull/579 adds ability to configure webhook via cli but this is part of repo create cmd, we could have a command which directly allow to configure existing created repo

[chmouel]

braindump of a new flow for bootstrap and setup. let us know if it make sense for you @siamaksade

synopsis

tkn pac bootstrap does the full bootstraping for providers (github-app/github-webhook, bitbucket, gitlab etc..) tkn pac setup is a new command we introduce to setup individual provider without doing the full bootstraping flow tkn pac update to update the current setup (for webhook)

flows

• tkn pac bootstrap: => dropdown:

  • do you want to bootstrap with a github-app

    • ask if we want to install pac
    • ask if want to create a github-app
    • let the user know to do a tkn pac repo create

  • do you want to bootstrap with a github-webhook

    • Run tkn-pac repo create (internally) to create repocr/namespace and pipelinerun if they user want.
    • ask for token
    • ask for webhook secret
    • create webhook with token provided
    • create a secret in the repocr namespace with the name of the repo
    • attach it to repocr

  • other provider same as github-webhook

• tkn pac setup github-app: setup only the github-app (move from tkn pac bootstrap)

• tkn pac setup github-webhook: setup only the webhook (move from tkn pac bootstrap --webhook flag)

• tkn pac update github-webhook: (NEW)

  • ask the user if they want to update webhook secret
  • ask the user if they want to update token

documentation update

• when creating github webhook for private repository we need an extra privileged (repo:webhok_creation) that is not needed to validate PR. If you like to drop that permission, you will need to recreate a token and run the command tkn pac update github-webook to update it.

[siamaksade]

I like the way you are thinking about it. Let's look at it from the other end. What are the things the user (sre-admin/developer) needs to do? These are what I can think of:

• [sre-admin] Install PAC: this though is handled through operator now. Do we still need to support it on CLI?
• [sre-admin] Create GitHub App
• [developer] Add Git repo using GitHub App
• [developer] Add Git repo using GitHub|GitLab|BitBucket Webhook (or re-add if they have happened to delete the webhook?)
• [developer] Update GitHub|GitLab|BitBucket access token on an existing webhook

How would you now map these use-cases to the CLI commands (existing or hypothetical)?

[chmouel]

[sre-admin] Install PAC: this though is handled through operator now. Do we still need to support it on CLI?

I think it's a good goal to make it easy to be able to be able to quickly try PAC, CRC+OSP+PAC may be a bit heavy on a laptop, while if you spin a kind cluster and run tkn pac bootstrap, you can literally get started to try pac in a few minutes.

Initially I wanted just that for the bootstrap command (quick demo bootstraping) but we ended up organically adding too many commands and flags into it and I guess this issue is to address that.

we do have commands (or flags) for those use case you are mentioning, but not a clear differentiation between "sre-admin" and "user" like "oc adm" and other "oc" commands would be.

I think it's a good idea, but we would need some clear design made on how we map each commands.

[siamaksade]

I think it's a good goal to make it easy to be able to be able to quickly try PAC, CRC+OSP+PAC may be a bit heavy on a laptop, while if you spin a kind cluster and run tkn pac bootstrap, you can literally get started to try pac in a few minutes.

Makes sense.

we do have commands (or flags) for those use case you are mentioning, but not a clear differentiation between "sre-admin" and "user" like "oc adm" and other "oc" commands would be.

I don't think we need to introduce the persona into the command but I just wanted to add the context of who does that thing.

This is how I would map these commands:

• [sre-admin|contributors] Install pac on the cluster (e.g. try locally on kind) and configures github app tkn pac bootstrap

  What's the use-case for bootstrap command to also handle the webhook flow? Given that most often it would be a different persona doing that

• [sre-admin] Create GitHub App tkn pac setup github-app

• [developer] Add Git repo using GitHub App tkn pac repo create

• [developer] Add Git repo using GitHub|GitLab|BitBucket Webhook (or re-add if they have happened to delete the webhook?) tkn pac repo create tkn pac setup github-webhook

  What do you think about "add" as the verb in both cases and consistent in the verb-noun order? For example add repo, add github-webhook, add webhook --type=github

• [developer] Update GitHub|GitLab|BitBucket access token on an existing webhook tkn pac update github-webhook

[chmouel]

Booked a meeting for tomorrow 10h15 CEST to talk about this together, meeting notes

[chmouel]

we can close this one as this has been done and another redesign has been done since then by @savitaashture :D