-
Notifications
You must be signed in to change notification settings - Fork 14.1k
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
chore: add required review on master #12694
chore: add required review on master #12694
Conversation
Should we try adding "Required" checks in |
Codecov Report
@@ Coverage Diff @@
## master #12694 +/- ##
==========================================
- Coverage 66.81% 59.01% -7.80%
==========================================
Files 1017 965 -52
Lines 49734 48099 -1635
Branches 4864 4421 -443
==========================================
- Hits 33229 28386 -4843
- Misses 16382 19713 +3331
+ Partials 123 0 -123
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
yeah, thanks @ktmud. I'm looking at this note in the docs, too: |
776e227
to
0f06745
Compare
0f06745
to
c057787
Compare
required_pull_request_reviews: | ||
dismiss_stale_reviews: true | ||
require_code_owner_reviews: true | ||
required_approving_review_count: 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
definitely would like a second pair of eyes on all this. I don't think there's a way to test before merging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only risk I see is the contexts are not correct. Let's just be ready to fix/revert if needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, yeah, I set up: #12698 and will rebase when this lands. We might as well wait until next week, too, to land this.
.asf.yaml
Outdated
- test-sqlite | ||
|
||
required_pull_request_reviews: | ||
dismiss_stale_reviews: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want this? It might cause some pain, say if a PR is approved but a rebase is needed before merging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good call. updated.
.asf.yaml
Outdated
- lint | ||
- test-mysql | ||
- test-postgres | ||
- test-sqlite |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a little unclear which names should the contexts use.
This API returns only the job name, with Matrix suffix:
curl -s \
-H "Authorization: token ${GITHUB_TOKEN}" \
https://api.github.com/repos/apache/superset/commits/master/check-runs | jq ".check_runs[] | .name"
"test-sqlite (3.7)"
"pre-commit (3.7)"
"Prefer Typescript"
"test-postgres-presto (3.8)"
"test-postgres (3.8)"
"babel-extract (3.7)"
"test-postgres (3.7)"
"lint (3.7)"
"build"
"License Check"
"build"
"test-postgres-hive (3.8)"
"test-postgres-hive (3.7)"
"frontend-check"
"test-mysql (3.7)"
"build"
"babel-extract (3.7)"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ktmud do you have these actions set up in your fork? If so, can you check the name that appears under the settings tab for the repo?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming the API will use the same names as displayed here?
We might want to rename a couple of our jobs to avoid confusion (there are a couple of duplicate "build"s).
I guess the safest route would be to have a very limited list here to override the admin settings, then add them back in a separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think those are the names we need to use, though they do look quite different than the names reported on PRs. I don't think the risk here is that high, I doubt committers will be merging PRs with failing status checks (even if they're not actually marked required). We could make and announcement just in case, "You might see some changes to the required checks as we figure things out, please don't merge anything that's failing a check"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The docs show them as <Action Name>/<Job Name>
:
contexts:
- gh-infra/jenkins
- another/build-that-must-pass
although I realize that the action name was missing in some of the tests when I pulled them in, so I can update that. Looks to me that we would have to provide the action name in order for the duplicated job names to even work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the risk here is that if you add checks not matching the actual context names as required, everyone will (may) be blocked from merging until INFRA intervenes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, that's a good point. We should probably do this during hours of low activity. Worst case, we revert quickly and none of the check will be required. Without the admin repo privileges we are kind of shooting in the dark though
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Following on this scenario, do you think all the "blocked" prs would automatically be mergable after we revert this? Do you think there's any risk that we won't be able to unblock them? I think worst case scenario, we should be able to close and open the pr to retrigger the checks, which would just be time consuming.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think rather than revert we'd want to set the context as empty or remove the ones that end up stuck
.asf.yaml
Outdated
- Python Misc/lint | ||
- Python MySQL/test-mysql | ||
- Python MySQL/test-postgres | ||
- Python MySQL/test-sqlite |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found a few other projects using this feature
https://github.com/apache/skywalking-eyes/blob/main/.asf.yaml
https://github.com/apache/skywalking/blob/master/.asf.yaml
https://github.com/apache/skywalking-python/blob/master/.asf.yaml
It seems they're using the portion after the /
, which would result in duplicates for us. I think this looks good to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect if a match isn't found in the list of recent contexts nothing happens
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect it will wait for that check forever... Maybe let's add a very short list to override the admin settings first, then gradually add them back?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When you go to settings you can't just enter any string, you have to choose from the list of "status checks found in the last week for this repository". I think it needs to be a context the repo has seen before. Also, here they have build
set but no check is marked as required.
https://github.com/apache/skywalking-client-js/blob/04dd6b3b024f838b3b92002a370ce3b7f70638b4/.asf.yaml#L38
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although, it may be a good idea to be extra safe here as we may end up in a stuck state waiting for apache infra.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested with a personal fork, now I'm 90% sure GitHub will just be forever waiting for these unidentifiable checks:
IMO the safest course of actions is:
- Update this PR to include only the simplest check (e.g. "check" for "PR Lint") in the required list, just to override manual admin settings.
- Once the CI passes, merge it.
- Make another PR to rename the jobs with ambiguous names
- Maybe another PR to add other required checks back to the "required" list. Could combine with 3, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, this is great. @ktmud it looks like three of four of those context strings didn't match any existing checks. Did "build" work and match to Frontend / build
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually based on your other screenshot, I think I should go with the whole string with the space PR Lint / check
for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the thorough investigation @ktmud. I think you're right, this file is just used to make a request to the github api.
.asf.yaml
Outdated
- Python MySQL/test-mysql | ||
- Python MySQL/test-postgres | ||
- Python MySQL/test-sqlite | ||
- PR Lint / check |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
based on how @ktmud's example, it looks like this is the proper format, and removed the others for now if we wanted to just test one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I think you need to remove the "PR Lint / " prefix, too (i.e. just use "check"). The contexts
config will only match the job name, not the workflow name.
See here the checks for Python MySQL / test-mysql (3.7)
here: NUDA5020#1
This is what I sent to the API:
{
"required_status_checks": {
"strict": true,
"contexts": [
"build",
"lint",
"PR Lint / check",
"check",
"Python MySQL/test-mysql",
"Python MySQL/test-mysql (3.7)",
"abc/def"
]
}
}
we could also if we wanted to mitigate risk, just push out the required reviewer change in this pr and then add the required context in a separate pr, too. |
4712772
to
395fcc4
Compare
aa60abc
to
8cc337c
Compare
8cc337c
to
97b93c2
Compare
Ok, this is updated to only require "check". The test on a different branch didn't work. So the plan then is to land this, which should only make PR Lint/ check required. Then if that works, we add |
I think it will match both jobs. And the CI will not be green unless both jobs pass. We should probably rename them before adding them back to required. |
Rerunning checks |
That worked! Looks like "PR Lint / check" is the only required check now |
* master: (23 commits) feat(explore): clear search on dataset change (apache#12909) chore: remove SIP-38 feature flag (apache#12894) fix: Config for dataset health check (apache#12906) fix(chart): allow null for most query object props (apache#12905) feat: add separate endpoint to fetch function names for autocomplete (apache#12840) chore: add required review on master (apache#12694) fix: comment typo (apache#12898) Migrates Radio component from Bootstrap to AntD. (apache#12738) fix: allow users to reset their passwords (apache#12886) fix(explore): missing select when groupby without metrics (apache#12890) refactor: dbapi exception mapping for dbapi's (apache#12869) feat(style-theme): add support for custom superset themes (apache#12858) chore(lint): fix pre-commit error (apache#12884) refactor(color-schemes): refactor setting of color schemes (apache#12857) feat(native-filters): Add defaultValue for Native filters modal (apache#12199) feat(release): add github token to changelog script (apache#12872) fix(menu): always show settings dropdown (apache#12877) Migrates Label component from Bootstrap to AntD. (apache#12774) [Helm] Automate datasource import (apache#10771) build: Skip loading example data from configs in CI (apache#12610) ...
SUMMARY
This change requires at least one approving review before committers can merge PRs to master. It should not (in theory) affect mergeability with regard to passing tests.
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features
ADDITIONAL INFORMATION