Provide example with actual GitHub release

[beatngu13]

First of all: thanks a lot for the excellent documentation Gluon provides! 🙏

I'm currently migrating a JavaFX app from Java 8 / Oracle Java VM to Java 11 / GraalVM, particularly to provide native images. When it comes to GitHub Actions, I currently have two workflows:

1. A main build that compiles and tests the project, including caching, code analysis etc. (Runs on every push.)
2. A release build that creates an actual GitHub release and uploads the artifact. (Runs only on tags matching v*.)

Since both workflows run on Linux and are independent from each other, this is not a big deal. Now, with native images for Linux, macOS and Windows, it gets a bit more complicated. What I'm thinking of at the moment:

1. A main build that does the same stuff as before, but also creates a native image for each OS for testing purposes.
2. A release build that (again) does the same stuff as before, but also creates a native image for each OS. And once they have been created, they should be added to an automatically created GitHub release.

I'm not 100 % sure, but I think this requires job/workflow synchronization -- if one doesn't want to put everything in one big workflow.

My question is: do you already have an example for this or something similar? If not, I'm happy to submit a PR once I have figured this out.

[erwin1]

Thanks for your feedback. I'm not sure if completely understand your workflow synchronisation requirement. Next to this sample, I'd suggest you also have a look at how Scene Builder is released https://github.com/gluonhq/scenebuilder. It doesn't use native image, but it does build releases/installers for various platforms.

If you have a better approach, we're very happy to accept PRs of course!

[beatngu13]

Hey @erwin1,

thanks for pointing me to the Scene Builder workflows, which are a good example.

When you look at the GitHub releases such as the most recent v15.0.1, you will see that it "only" contains the default assets – which is the source code as zip and tar.gz. In contrast, my project's releases also contain the actual artifact. See, for example, v0.7.0. (It's currently only a jar file, but as mentioned earlier, I'm migrating to native images.)

The point is, when using Gluon/GraalVM, the native image creation needs to run on three different OS. Once the corresponding native images have been created, they should be added to the GitHub release as assets. This, I guess, requires some sort of synchronization between the creation of the native images and the creation of the GitHub release. Scene Builder doesn't face this issue, because the bundle workflows only run on tagged commits and upload the result to S3.

So, if you already have an example for the aforementioned workflow, please let me know. If not, and if you would find this helpful, I can open a PR as soon as I have wrapped my head around it.

[erwin1]

Do I understand it correctly you want one release' including the binaries for 3 different platforms? If that's the case, we haven't done that before. It might be worth investigating if you could use a Draft release and update that from different workflows.

[beatngu13]

@erwin1 I decided to use a single workflow file with separate jobs, since synchronization between jobs is easier:

First, there's an ordinary Maven build (verify) job. If that one succeeds, three jobs follow creating native images on Linux, Mac and Windows. If the push event is actually a tag, a GitHub release is created that includes the native images as well as a fat JAR.

Workflow file: https://github.com/beatngu13/pdf-zoom-wizard/blob/develop/.github/workflows/build.yml Example release: https://github.com/beatngu13/pdf-zoom-wizard/releases/tag/v0.9.0

Let me know if you want me to create a PR for your repo. Otherwise, feel free to close the issue. And thanks for your help!