gh: adding a freeze window workflow

confidential-containers / cloud-api-adaptor

Ability to create Kata pods using cloud provider APIs aka the peer-pods approach

Apache License 2.0

44 stars 71 forks source link

gh: adding a freeze window workflow #1801

Open beraldoleal opened 2 months ago

beraldoleal commented 2 months ago

Maintainers can enable/disable this workflow via web interface. When enabled all PRs will have at least one test failing.

stevenhorsman commented 2 months ago

Hey Beraldo, I just want to fully understand the proposal so if it works out we can add it to the release process docs and there are a couple of questions/concerns I have:

For getting the release related PRs (version bumps etc) through is the intention that a maintainer would disable, merge that PR and then re-enable this workflow?
Is this supposed to be enforcement, or just a reminder? If we don't make this check required then it won't block PRs merging, but if we do make it required then it blocks merging when it's enabled and fails, but also blocks when it doesn't run. A reminder if better than nothing, but I just wanted to check what you had envisaged.

stevenhorsman commented 2 months ago

The other approach I was thinking about is whether we could have a freeze label, and then a permanent job that checks if freeze, or WIP is labelled and that could be required (kata has this step up). I think using the gh api we could probably easily write workflows to label & unlabel all current PRs with this, but I don't have a good idea for how we would set it up so a new PR created during the freeze period would get labelled. I thought I would share in case others have thoughts though.

beraldoleal commented 2 months ago

Hi @stevenhorsman the idea here is that one test will be failing and the "Rebase and merge" button will be disabled. During the release period, admins could use their privileges to merge only PRs related to the release process.

We could use this same PR as example. I guess one test is failing but I'm assuming you could merge it anyway, right?

After the release is over, we could disable the workflow using the GH ui. The job would be permanent, the only difference is that it would be disabled for non-freeze periods. Having a job checking for a label all the time is an viable option as well, but this approach would be saving some CI hours/resources.

stevenhorsman commented 2 months ago

We could use this same PR as example. I guess one test is failing but I'm assuming you could merge it anyway, right?

This is the point I was trying to explain - I don't think it will block merging unless it's a required job. At the moment we can merge this due to not having 2 reviews, not the failing test:

beraldoleal commented 2 months ago

We could use this same PR as example. I guess one test is failing but I'm assuming you could merge it anyway, right?

This is the point I was trying to explain - I don't think it will block merging unless it's a required job. At the moment we can merge this due to not having 2 reviews, not the failing test:

Humm I see now. Yes GH removed the required checks feature, and looks like we can do that via project/repository settings using rulesets, but I don't have permissions to see that here.

stevenhorsman commented 2 months ago

Humm I see now. Yes GH removed the required checks feature, and looks like we can do that via project/repository settings using rulesets, but I don't have permissions to see that here.

Yes - I can make it a required check, but that means it will have to run even when we aren't in freeze and block otherwise (we have similar issues in kata-containers around this)