Add Kops required status checks

[mikesplain]

Adding kops to branch-protection for github actions, as discussed in kubernetes/kops#9005.

I believe this will also remove the existing travis ci block so we'll need to add that here if we wish for it to continue to block.

Thoughts @rifelpet, @hakman, @johngmyers ?

/hold

[mikesplain]

/assign @rifelpet

[rifelpet]

two thoughts:

1. We should consider adding the travis ci check here. Once we make this blocking we'll be able to remove all of the travis jobs except the ARM64 build. I know @hakman made that individual job non-blocking but eventually we'd want to make it blocking as ARM64 support stabilizes. If we add travis here and the only travis job is configured to allow failure, will tide still treat PRs as mergeable if the ARM64 job fails?

2. It'd be nice if we had more stable names for the github action jobs so that as we upgrade the OS or go versions we don't need to update these references (since they require test-infra approvals) Any idea if github actions support customizing the names from jobs' matrixes to make them more stable? I don't have a good suggestion on what to name them though. Maybe this isn't a big deal since we dont update either OS or go versions very often.

[mikesplain]

two thoughts:

1. We should consider adding the travis ci check here. Once we make this blocking we'll be able to remove all of the travis jobs except the ARM64 build. I know @hakman made that individual job non-blocking but eventually we'd want to make it blocking as ARM64 support stabilizes. If we add travis here and the only travis job is configured to allow failure, will tide still treat PRs as mergeable if the ARM64 job fails?

Agreed, just added this as well. This should block on travis the way it does now. I believe this will continue to work even when we disable the old jobs, since the travis job should still pass since the allow failure flag is set. I went with continuous-integration/travis-ci/pr though it's possible just continuous-integration/travis-ci would work.

2. It'd be nice if we had more stable names for the github action jobs so that as we upgrade the OS or go versions we don't need to update these references (since they require test-infra approvals) Any idea if github actions support customizing the names from jobs' matrixes to make them more stable? I don't have a good suggestion on what to name them though. Maybe this isn't a big deal since we dont update either OS or go versions very often.

I agree but I wasn't able to come up with a better way at the moment. There is something nice about being explicit about the block, for instance if we want to start testing on a new OS and start blocking later. How about I add a comment to our actions mentioning that an update is required here in order to start blocking when action names/matrix change?

[rifelpet]

Adding a comment to our actions sounds great 👍
/lgtm

[mikesplain]

Comment added in PR, will unhold kubernetes/kops#9305 when this is merged and confirmed.

Ready for review!
/assign @chases2

/unhold

[johngmyers]

/lgtm

[mikesplain]

/assign @cblecker

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: chases2, mikesplain

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• config/OWNERS [chases2]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

@mikesplain: Updated the config configmap in namespace default at cluster default using the following files:

• key config.yaml using file config/prow/config.yaml

In response to this:

Adding kops to branch-protection for github actions, as discussed in kubernetes/kops#9005.

I believe this will also remove the existing travis ci block so we'll need to add that here if we wish for it to continue to block.

Thoughts @rifelpet, @hakman, @johngmyers ?

/hold

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[hakman]

Small problem, I think this applies to all Kops branches, which pretty much blocks 1.6 and 1.17.
kubernetes/kops#9331

[mikesplain]

@hakman Good point. I’ll create a follow up. Thanks!