Prow Approval Flow [post-mortem]

kasiakepka commented 2 years ago

Background

With this issue we would like to track next steps after revering "Prow Approwal Flow" and revise results of that change. See here a little bit of history why it was reverted.

The change was aimed at improving developer experience and accelerating review process (see here) but it also appeared to be a big security topic.

What we did as a post-mortem

We decided to review changes implemented with this change and tried to evaluate whether we want or need to implement them once again. As an end result we created list of below requirements.

Must have: Secure release process. Options to implement:

Use protected tags. Only dedicated people will be able to create GH tags and create release.
Setup small automation that will notice accidental release and clean it up. There will be no user impact.
Resurrect Prow Approval flow and revoke write permissions.

Nice to have: Make review requests more accurate. Make notifications less noisy. Options to implement:

Github based solution with one lengthy CODEOWNERS file.
Prow based solution where write permissions are revoked.
Do not implement and wait for modularisation.

See below graph with all pros and cons as well as cost of implementation. See also Mural

Other remarks

OSPO guidelines for reference:

Project Members. You have standard write permissions to the repository and can contribute code and content (e.g. in issues, pull requests, discussions etc.) source

Note: We have to take into account upcoming modularisation changes.

kasiakepka commented 2 years ago

Meeting summary.

Three implementation options will be discussed quickly within the teams to make sure we all have common understanding. People who joined the call will share detailed information with their teammates.
Teams will vote internally and sum up the votes (i.e. 2 votes for option 2 and 4 votes for option 3)
SM will send those results to SM Slack chat (till Monday afternoon). Team X: option1: 0 votes , option2: 0 votes, option3: 0 votes
Results will be presented on Tuesday, here on Github.

m00g3n commented 2 years ago

All Wookiees are up for option 2 and option 3 (we may need the tags back if the release process change and we will have own repo but in current process option 3 is justified).
We also think it is up to Neighbors to decide about turning on/off the automatic assignment of a reviewer in prow repo.

dekiel commented 2 years ago

We went for GitHub auto review assignement feature for prow team. Check this comment for details https://github.com/kyma-project/community/issues/613#issuecomment-1152155808

jeremyharisch commented 2 years ago

The Jellyfish now decided and we voted for Option 3 to go with the protected Tags.

Team Jellyfish: option1: 0 votes, option2: 2 votes, option3: 8 votes

lilitgh commented 2 years ago

Huskies and Tunas voted for Option 3

Disper commented 2 years ago

Framefrog were preferring either options 2+3 or just 3.

majakurcius commented 2 years ago

Hasselhoffs voted for option 3. Team Hasselhoff: option1: 0 votes, option 2: 0 votes, option 3: 5 votes

kasiakepka commented 2 years ago

So we have the winner: `Use protected tags` (option 3 )

I know that Goats ale also for option 3, not sure what about Gophers but still option 3 wins.

kyma-project / test-infra