On Sat, 24 Oct 2020 14:49:37 GMT, Kevin Rushforth <k...@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
