RFR: 8256127: Add cross-compiled foreign architectures builds to submit workflow [v5]

[Aleksey Shipilev]

On Wed, 11 Nov 2020 21:57:47 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Aleksey,
>> 
>> I'm not at all sure I want to accept these changes. I understand that you care about these exotic platforms, and so do I, but adding them to the submit workflow for *all* changes seem like the wrong way to proceed.
>> 
>> My concern vary all the way from increased build time, to increased usage of the Github CPU quota (which, as I understand it, is fairly large but not unlimited), to the elephant in the room: the question on who the burden lays to fix bugs in these exotic platforms. It is not at all obvious that these builds should be tested before commit.
>> 
>> I think this change warrants a much wider and deeper discussion about the purpose of the Github commit hook actions, how the free Github CPU quota should be spent, and on whom the responsibility lays to either make sure no. commit is pushed that breaks an exotic platform, or to rectify the problem with a follow-up issue.
>> 
>> I recommend you withdraw this PR and instead initiate a wider discussion on a suitable mailing list, e.g. jdk-dev.
>
> Maybe it would be possible to build hotspot only as this is the part where things often break? This would save a lot of CPU time.
> E.g. I think it'd be valueable to have at least one Big Endian platform included.
> I noticed that some Oracle people use cross builds to check their changes on these platforms. It would save a bit of their time as well.

> I'm not at all sure I want to accept these changes. I understand that you care about these exotic platforms, and so do I, but adding them to the submit workflow for _all_ changes seem like the wrong way to proceed.

I understand the first reaction, but please read the updated description. It includes the discussion what bugs it tries to catch, and updated cost estimates. 

Submit workflow is a convenience thing for better testing coverage. Having the early warnings for fixable issues in foreign architectures helps to avoid follow-up churn without increasing the costs all too much. Do note that it does not require contributors to fix the runtime issues in foreign architectures, it only asks for passing a rather low bar of _not breaking the builds_ for them, which is, in my experience, an easily achievable goal. It is easily achievable because --  I am speaking from experience of fixing a lot of them over the years! -- the overwhelming majority of arch-specific build breakages are about silly things that are obvious from the build logs.

So I am leaving this PR open, letting others to chime in. If there is really a need for a wider discussion here, I could start a thread at jdk-dev@, but so far it does not look as a good use of our collective time. Please read through the description, and see if that soothes your concerns.

Aside: the issues about costs were [raised before](https://mail.openjdk.java.net/pipermail/skara-dev/2020-October/003581.html), but I think all of them resolve as "enjoy your free tier". If we target to optimize the GH action costs, IMO we should instead consider to avoid triggering them on every push, as [I hinted before](https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004739.html), and which I think requires better Skara integration (i.e. for `/test` command). Meanwhile, this PR gives us extended build coverage at fraction of the additional cost.

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

PR: https://git.openjdk.java.net/jdk/pull/1147