[External] : Re: Clarification regarding the GitHub Actions pre-submit testing

Stuart Marks stuart.marks at oracle.com
Thu Mar 18 22:19:44 UTC 2021

On 3/18/21 2:06 AM, Roman Kennke wrote:
> I am not quite sure why all of this even needs discussing. Besides GHA, we currently 
> have *zero* gating checks in OpenJDK workflow. Yes we used to have jdk-submit repo, 
> but that was *very* awkward. What GHA provides us is so much more useful and 
> accessible IMO.

I'm mainly objecting to (a possibly implicit) hint that GHA ought to be considered 
some kind of gating check, for the reasons I outlined in my reply to Alexey.

Or I might have misinterpreted things and there was no such suggestion; if so, ok.

I agree that GHA is much more useful and accessible than jdk-submit.

> If you don't like it, well, then I think it's ok to ignore it and rely only on 
> vendor-internal testing. My opinion is that checking GHA results and fixing obvious 
> build breakages is an action of minimal respect vs the wider OpenJDK community and 
> the various porters, and most often doesn't cost very much (or nothing at all). If 
> something shows up that doesn't look related to your change, you can still ignore 
> it, or, if you have some ideas, ping the right people.

Again, I agree, GHA is good for pointing out things like obvious build breakages.

The kind of thing I'm concerned about here is if (say) some machine off in the cloud 
that nobody in OpenJDK has control over has its multicast networking misconfigured, 
or there's a DNS outage or something, causing a bunch of tests to fail. Internally, 
if this were to happen, we can track it on an outage board, or remove misconfigured 
or faulting machines from the pool, etc. If this were to happen in GHA then ... ?

(In fact this scenario can't happen today, because AFAIK the GHA actions don't run 
the networking tests. But this scenario *will* happen when somebody gets the bright 
idea to add those tests to GHA.)

So yes, GHA is useful, but we should take it for what it is, which is a bunch of 
systems that we hope provide useful results, being maintained by volunteers.


More information about the jdk-dev mailing list