Prow will not able to check Travis context as Travis migrating off old status context API

[Sen Lu]

tl;dr

If you don't have Tide manages auto merge for your repo, or if you are not using Travis in your repo, you can stop reading now:

Slightly modified version from stevekuznetsov@'s notice:

FYI Travis seems to be finally migrating off of the old status context API and to the new checks api. This means that `tide` and `prow` in general cannot interact with it anymore. Specifically, the following repositories currently require the old status context in branch protection, which will mean that PRs where Travis reports using the Checks API have an un-run but required status from Travis, blocking merge:

`kubernetes/`
- `dashboard`
- `dns`
- `kompose`
- `kubectl`
- `repo-infra`
- `utils`
`kubernetes-client/`
- `python`
- `python-base`
`kubernetes-csi/`
- `csi-test`
- `drivers`
- `external-attacher`
- `external-provisioner`
- `external-snapshotter`
- `livenessprobe`
`kubernetes-incubator/`
- `apiserver-builder`
- `bootkube`
- `cluster-proportional-autoscaler`
- `external-storage`
- `kube-aws`
- `metrics-server`
`kubernetes-sigs/`
- `kube-batch`
- `node-feature-discovery` (edited)

All of the repos above must remove the requirement for Travis soon or they will block their merge queues. Furthermore, as Travis is now using Checks, we can no longer enforce that it is green before merging. If someone has the checks api required on their repo, `tide` will try to merge (as, for all it can see, everything is ready) but fail repeatedly as the check is not green

Those contexts can't be used anymore, so please migrate your jobs from Travis to Prow to avoid merge queue being stalled for your repos :-)

Thanks!

Best,

Sen
--

-------------------------------------------------

Sen Lu

Software Engineer

Google Kubernetes Engine - EngProd Team

[Patrick Ohly]

'Sen Lu' via Kubernetes developer/contributor discussion
<kuberne...@googlegroups.com> writes:
[...]

> All of the repos above must remove the requirement for Travis soon or they
> will block their merge queues.

Who can do that done and how? Travis CI test results can be ignored for
all of the Kubernetes-CSI repos because Prow already runs the same
tests, but we cannot turn off Travis CI because image publishing from
Prow jobs isn't possible yet.

--
Best Regards

Patrick Ohly

[Wojciech Tyczynski]

 How did you check the repos above?

 I think we're also relying on travis in perf-tests, e.g.:
https://github.com/kubernetes/perf-tests/pull/536

 Which means maybe there can actually be more than that.

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CA%2BSjBsRt_Xbt0m%2BrTbTqiEgWMgg45OO87sy7muki6t2qqs%2BxWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Steve Kuznetsov]

Anyone may do so, all that is necessary is to remove the configuration
for Prow [1]

[1] https://github.com/kubernetes/test-infra/blob/58b85f6993675120a07980a50201fa37c892b16f/prow/config.yaml#L254

[Steve Kuznetsov]

Please check the Prow configuration (ex [1]). Today it looks like
perf-tests does not require Travis to merge.

[1] https://github.com/kubernetes/test-infra/blob/58b85f6993675120a07980a50201fa37c892b16f/prow/config.yaml#L254

[Wojciech Tyczynski]

On Fri, May 24, 2019 at 5:12 PM Steve Kuznetsov <skuz...@redhat.com> wrote:

Please check the Prow configuration (ex [1]). Today it looks like
perf-tests does not require Travis to merge.

Hmm - this is what I'm seeing in one of the PRs:
https://screenshot.googleplex.com/AD4ZFqwtNw0

It seems to be required (or at least comments suggest that).

[Steve Kuznetsov]

I can't access the link, but what I assume is happening is that Tide
can be configured to always require unknown statuses that it finds on
PRs, and has been configured to do so in this case. This is different
from requiring the status through branch protection (which should make
the "Required" box show up in the GitHub UI and would be handled with
the configuration changes linked above.

[Sen Lu]

Hi Wojciech - do you still have a PR currently stuck on merging in your repo?

-------------------------------------------------

Sen Lu

Software Engineer, Tools and Infrastructure

Google Kubernetes Engine - EngProd Team

Google - Inc

[Wojciech Tyczynski]

On Tue, May 28, 2019 at 3:03 AM Sen Lu <se...@google.com> wrote:

Hi Wojciech - do you still have a PR currently stuck on merging in your repo?

https://github.com/kubernetes/perf-tests/pull/534

[To be clear: I expect that to be stuck, so it's not that I think it's wrong. I just want to understand how it works] 

[Sen Lu]

I think Travis status is not a "required" context for your repo since that's not part of branch-protection config. Steve or Cole can confirm.

[Steve Kuznetsov]

Right so as I mentioned before:

Tide is configured to honor statuses it does not know about on your
repo, so if it finds a failing Travis context it will not want to
merge until it notices no failing context.

This is not the same as requiring the context via branch protection
and explicitly -- for instance, the current configuration will not
block merge if the Travis context is missing, for example.

When the repo is migrated to travis-ci.org and Travis begins to use
the GitHub Checks API, none of this is relevant as Tide is not able to
see those statuses in any way.