Status of GitHub automatic tier1 testing

Thomas Schatzl thomas.schatzl at
Fri Oct 2 14:02:57 UTC 2020

Hi again,

   just to clarify my statements:

On 02.10.20 15:48, Thomas Schatzl wrote:
> Hi,
> On 02.10.20 15:41, Robin Westberg wrote:
>> Hi all,
>> As you may have noticed when pushing changes to your personal forks 
>> recently, GitHub will now automatically trigger basic tier1 testing on 
>> the supported platforms (currently Linux, Windows and macOS, all x64). 
>> If all goes well you may not even notice it as it defaults to sending 
>> a notification only if anything should fail.
>> However, please note that the first version of this automatic test 
>> execution contained a problem that could cause it to not detect 
>> failing test cases. I know there have been a few test errors that have 
>> gone by unnoticed due to this for which I’m sorry. The good news is 
>> that the problem is now fixed starting with 
>> - so make sure that your branch contains this change if you plan to 
>> look at the test results!
>> Apart from this there are now no known issues with these pre-submit 
>> tests, so if you run into any problem, please let me know. If these 
>> tests turn out to be reasonably stable and trustworthy, the next step 
>> will be to present a summary of the results in the body of PRs to make 
>> them more visible.
>> Best regards,
>> Robi
>    thanks for your effort.
> I would like to ask for a way to opt out - the public personal may 
> receive unfinished work that may not even compile in a lot of cases. So 
> this pre-checking seems like a waste of cpu time in a lot of cases and 
> another notification I do not want in my inbox.
> After the fifth or so a day I'll probably just ignore it anyway.
> Also there are a significant amount of pushes that are done just fixing 
> a typo in a comment or such, again wasting time.

That particularly tends to happen a lot when I do the final check for a 
draft PR. I tend to keep the public personal fork fairly clean and only 
push when I am ready to create a draft PR.

But I also know a few personal openjdk forks that seem to do all of 
their development in the open and potentially push their work at the end 
of the day in whatever state it is (idk really, but I do that in a 
private repo).

They will just get annoyed by unnecessary emails (and it really just 
wastes cpu time).

> I can somewhat understand such testing for different situations.
Eg. when publishing a PR, or maybe changing a fork that has a published 
PR. Or before integration with the option to override due to unrelated 


More information about the jdk-dev mailing list