Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gh: adding a freeze window workflow #1801

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

beraldoleal
Copy link
Member

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

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

Signed-off-by: Beraldo Leal <[email protected]>
@stevenhorsman
Copy link
Member

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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:

image

@beraldoleal
Copy link
Member Author

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:
image

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
Copy link
Member

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants