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

[Mario Torre]

In practice you have “volunteers” already, those are the port maintainers.

I would expect that if an Oracle patch breaks Shenandoah for example Roman would be quick in fixing it. In the past when this happened we would notice when pulling and testing internally, now a GHA would tell before.

I don’t think the latency would increase too much so it can be an hard gate but a soft gate is better than nothing. Said Oracle engineer may decide that the fix is a trivial one liner or that it requires more work and is better to ask for a followup.

Essentially, all this already happens, GHA just makes it more explicit.

Cheers,
Mario

—
Mario Torre
Java Champion and OpenJDK contributor

PGP Key: 0BAB254E
Fingerprint: AB1C 7C6F 7181 895F E581 93A9 C6B8 A242 0BAB 254E

Twitter: @neugens
Web: https://www.mario-torre.eu/
Music: https://mario-torre.bandcamp.com/

> On Thursday, Mar 18, 2021 at 23:20, Stuart Marks <stuart.marks at oracle.com (mailto:stuart.marks at oracle.com)> wrote:
>
>
> 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.
>
> s'marks
>