Test-infra: Allow protecting the tide github status context
What would you like to be added:
When reporting Prow jobs status for PRs in Github UI, also note whether it's required or optional as defined by Prow job itself
Why is this needed:
This can help remove the ambiguity introduced by hidden required jobs that only required by tidebut not explicitly marked as required by admins. Also, this will make it possible to only require tide as requirement
chaodaiG
All 8 comments
Looks like you have branch protection configured and it's clearly marking the job as required on the right of your screenshot -- is what you're asking for a separate feature?
stevekuznetsov
on 25 Feb 2020
The example was from a PR in the current repo. The goal of this feature request is to make us being able to only add tide on branch protection instead of adding each individual job
chaodaiG
on 25 Feb 2020
To be more clear, this is just a UI change request. As functionally we can already only add tide to branch protection, since tide already implicitly requires all jobs that are not marked optional to pass. So the ask is just labeling each job more explicitly in Github UI.
IMHO this is achievable if the status updater already knows about optional, otherwise it may not worth the effort to wire them together
chaodaiG
on 25 Feb 2020
/retitle Allow protecting the tide github status context
The example was from a PR in the current repo. The goal of this feature request is to make us being able to only add tide on branch protection instead of adding each individual job
This can be done today _but_ will result in an elevated error rate from tide, because the part that updates the status is async from the part that merges, which means that the merging may fail because the github status context wasn't updated yet.
Generally this is a huge +1 from me, as its conceptionally much saner than protecting each individual github status context, because that requires a giant amount of tokens and the settings are only eventual consistent with job config changes.
alvaroaleman
on 27 Feb 2020
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
on 27 May 2020
Related to this asynchronousness, sometimes PRs will merge before their tide status is updated. This leads to some PRs (like https://github.com/kubernetes/test-infra/pull/17874) that will merge even while the Tide status says the PR is "not mergeable". This has been observed to happen on multiple repositories.
/remove-lifecycle stale
chases2
on 8 Jun 2020
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
on 26 Nov 2020
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
fejta-bot
on 26 Dec 2020
Related issues
fejta
路
4Comments
zacharysarah
路
3Comments
MrHohn
路
4Comments
spiffxp
路
3Comments
cblecker
路
4Comments
Most helpful comment
/retitle Allow protecting the tide github status context
This can be done today _but_ will result in an elevated error rate from tide, because the part that updates the status is async from the part that merges, which means that the merging may fail because the github status context wasn't updated yet.
Generally this is a huge +1 from me, as its conceptionally much saner than protecting each individual github status context, because that requires a giant amount of tokens and the settings are only eventual consistent with job config changes.