Clarification regarding the GitHub Actions pre-submit testing

Andrew Hughes gnu.andrew at redhat.com
Thu Mar 18 18:25:21 UTC 2021


On 16:51 Thu 18 Mar     , Andrew Haley wrote:
> On 3/18/21 1:18 PM, Aleksey Shipilev wrote:
> > Taking current state of Loom as the example: it has lots of direct uses of x86-only definitions from 
> > the shared code. As I said before, it is a fair game for non-mainline development to hack the 
> > prototypes any way they want, including focusing only on one platform at a time. But if we decide to 
> > integrate current Loom into mainline, then GHA would complain that foreign arches are not buildable, 
> > and that would point to this not-yet-reconciled cohesion between shared and arch-specific code. That 
> > is, GHA would be a very basic quality gate working as intended.
> 
> The question is this: on whom does the buildability requirement rest?
> 
> If we are to allow many ports into OpenJDK, and I believe we should,
> then the burden of even stubbing things out to make sure that all
> weird ports work is intolerable for contributors. It can not scale.
> 
> I say, therefore, that it's for the maintainers of those ports to
> fix things up, before a patch is committed if they can, after if
> they can't.
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 

This is nothing new; I've lost count of the number of times the
Zero assembler port has been broken by changes to HotSpot over
the years, and that doesn't even require configuring a different
operating system and/or architecture, just a build flag.

On the other hand, we've been expected to blindly fix build failures
on Oracle build systems before, including on systems like Solaris
where we don't build ourselves. At first, this was only indirectly via
an Oracle sponsor, and then the jdk-submit system, which was also not
required in any Bylaws or even documented clearly on the OpenJDK
website. Yet, we were expected to use it and fix issues on whatever
the build configuration was there e.g. [0].

It feels to me like the GitHub setup brings a little equality to this
situation. Now there is better coverage and everyone has the same
access to the build systems and results, as far as I can see.

I agree with Roman & Aleksey that having a pass on this should be
a requirement. This also means making it a requirement for GitHub
Actions (GHA) to be setup before proposing a PR.

I think doing so is basic community responsibility, where you try
and minimise the effect your work has on others. It also works
both ways; if you don't break the ports of others, then they
won't break yours.

I think the burden here is being overstated. There is no requirement
to do anything to activate these tests after the initial setup; I
actually ended up testing something I didn't even file a PR for, until
I found how to filter out certain pushes to the branch! [1] The
majority of patches will pass straight away, because they are either
pure Java or don't make arch-dependent changes to the code.

What this will catch is where a new function needs to be defined for a
particular port or a particular compiler dislikes a line of code.
Given you have the build log, it is likely to be a simple fix. No-one
is expecting you to port the code to that setup; a stub will do.
You're also not in isolation; catching such things is a good time to
flag the issue to the maintainers of that port. By far the biggest
problem in my experience is that port maintainers often aren't aware
of the breakage until they discover it themselves further down the
track, so the build failure at the time of PR alone is helpful.

Where we can perhaps draw a compromise is on the systems that go
through this testing. If the systems building a particular port
regularly throw up spurious failures, or the port maintainers are
unresponsive, then it should be dropped from the setup by community
consensus. But I see no reason to abandon the whole thing because of
the hypothetical case that some port may be troublesome in the future.

If we do choose not to make this a requirement, I think it sends a
very selfish message that people only care about their own particular
setups and are quite happy to unknowingly break the work of others
without even engaging with them to fix it.

[0] https://bugs.openjdk.java.net/browse/JDK-8243114
[1] https://wiki.openjdk.java.net/display/SKARA/Testing
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222


More information about the jdk-dev mailing list