RFR: 8254691: Enable GitHub actions for jfx repo

[Johan Vos]

On Sat, 24 Oct 2020 14:49:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This is a proposed fix for [JDK-8254691](https://bugs.openjdk.java.net/browse/JDK-8254691) to enable GitHub actions for the jfx repo. It is similar in purpose to what was done for the jdk repo.
>> 
>> Once this is integrated, and subsequently merged into your personal fork, a GitHub Actions workflow will run on every push to any branch in your personal fork except a production branch (so that syncing the upstream `master` or `jfx*` branch won't cause a build) or any branch whose name that starts with `WIP`.
>> 
>> The workflow does a build and (headless) test run on all three platforms: Linux, macOS, and Windows. The build is done without building the native media or WebKit libraries. Web tests are excluded.
>> 
>> Here is the job that resulted from the most recent push to the `8254691-github-actions` branch in my personal fork:
>> 
>> https://github.com/kevinrushforth/jfx/actions/runs/329355746
>> 
>> The workflow checks out the sources for the branch, downloads the boot JDK, installs the needed software packages, and then runs two build steps, `gradlew all` followed by `gradlew test -x :web:test`.
>> 
>> The Skara tooling will process the results of the GitHub actions run, and show them in the **Testing** section of a pull request, as you can see below.
>> 
>> Follow-on work:
>> 
>> 1. Get BOOT JDK parameters from `build.properties`. Currently the location of the bootJDK is hardcoded in the [`submit.yml`](https://github.com/kevinrushforth/jfx/blob/8254691-github-actions/.github/workflows/submit.yml) file. This should be obtained from build.properties; we might need to add a couple more properties.
>> 
>> 2. Check the shasum of the downloaded bootJDK and enable caching of the JDK (in order to save download time). This requires step 1 to be done first.
>> 
>> 3. Locate the Visual Studio compiler on Windows. The location and version of the Microsoft Visual Studio 2019 compiler is hard-coded which will break if and when the GitHub build farm updates their Windows system. This will require making our build itself a little smarter, possibly using `vswhere`.
>
> @rwestberg I was pleasantly surprised to see the Skara bot add this:
> 
>>  | Linux x64 | Windows x64 | macOS x64
>> -- | -- | -- | --
>> Build / test | ✔️ (1/1 passed) | ✔️ (1/1 passed) | ✔️ (1/1 passed)
> 
> I was going to ask you what I needed to do so that you could generate this. I guess the short answer is that what I've already done is sufficient. Thanks!

> @rwestberg I was pleasantly surprised to see the Skara bot add this:
> 
> > Linux x64
> > Windows x64
> > macOS x64
> > 
> > 
> > 
> > 
> > Build / test
> > heavy_check_mark (1/1 passed)
> > heavy_check_mark (1/1 passed)
> > heavy_check_mark (1/1 passed)
> 
> I was going to ask you what I needed to do so that you could generate this. I guess the short answer is that what I've already done is sufficient. Thanks!

I noticed this in the openjdk/mobile repository as well, and that looks great. In that repository, there seems to be a different configuration, as there is a line for "build" and a line for "test/tier 1" ( e.g. https://github.com/openjdk/mobile/pull/10 )

I wonder how configurable this is?

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

PR: https://git.openjdk.java.net/jfx/pull/338