Both nightly build and release workflow build the native image (via matrix OS for each involved target platform OS/arch).
There are several things to improve:
we want to support more target platforms (see e.g. #337)
on the according platform builds (matrix os steps) we should IMHO only build the native image and upload it but do nothing else
on the main build machine we should do the full build except for the native-image and just collect the native images build before. This includes building the documentation, building the gui, and for the cli finally build the assembly with everything together (documentation + native images + scripts and other package resources).
What I also do not get is where do we do the "loop" over all OS combinations in the main build? Actually I would expect that either in the workflow build or in our CLI POM or in the assembly we define that we want to have a release for win-x64, max-x64, mac-arm, linux-x64 (and potentially more). In the POM I see this:
https://github.com/devonfw/IDEasy/blob/dd966b4a603d68f0693b07c8a76d63dd626421f9/cli/pom.xml#L18C5
So for the native-image build this somehow makes sense to me. But how does the main build finally create multiple OS/arch specific releases? My only explanation is that he does not at all but just downloads all that was uploaded from the matrix OS builds and maven just attaches them as artifacts and therefore includes them as-is into the deploy. Therefore, I see that we will need some rework. I still also do not get why the nightly build failed lacking the documentation to include while the release build did not fail. Why is that? To me this does not make sense.
BTW: I do not want to cause extra complexity. We can also stay with the approach that the native matrix OS build is already building the full package and target release. However, then before we would need to build things like the documentation first and then include that single documentation into all the matrix os builds (via maven repo? or via GHA uploads/downloads). I just have the impression that this will all make it much more in-transparent and therefore complex.
Currently, I do not fully understand what is going on and I would consider myself as a maven expert. So who will then be able to understand it and is capable to improve and apply fixes in the future? So we should find a simple and understandable solution and for what remains complex we should add documentation (e.g. comments or even asciidoc file explaining how all works together with GHA, maven, assembly, etc.).
And the most simple approach would be to build everything on the same node/VM. However, since GraalVM does not support cross-compiling, we can only build native-image for Mac on a MacOS machine and the same for Linux and Windows. Therefore my vision is that the main build is doing all OS independent stuff (doc, build JARs, run tests, etc.) and this only delegates the native image build on the other machines. It is IMHO acceptable if those matrix OS builds all compile the Java code redundantly but building the documentation 3,4,.. times with different timestamps on the front-page, etc. or esp. running the JUnits redundantly for each OS/arch seems like waste and very odd. Otherwise we could even have done the full build redundantly on each OS but the problem with this simple approach is that we cannot tag git and create github releases redundantly and if then one OS succeeds and the other fails, we end up with a partial release that is published but incomplete.
Both nightly build and release workflow build the native image (via matrix OS for each involved target platform OS/arch). There are several things to improve:
gui, and for theclifinally build the assembly with everything together (documentation + native images + scripts and other package resources).What I also do not get is where do we do the "loop" over all OS combinations in the main build? Actually I would expect that either in the workflow build or in our CLI POM or in the assembly we define that we want to have a release for win-x64, max-x64, mac-arm, linux-x64 (and potentially more). In the POM I see this: https://github.com/devonfw/IDEasy/blob/dd966b4a603d68f0693b07c8a76d63dd626421f9/cli/pom.xml#L18C5
So for the native-image build this somehow makes sense to me. But how does the main build finally create multiple OS/arch specific releases? My only explanation is that he does not at all but just downloads all that was uploaded from the matrix OS builds and maven just attaches them as artifacts and therefore includes them as-is into the
deploy. Therefore, I see that we will need some rework. I still also do not get why the nightly build failed lacking the documentation to include while the release build did not fail. Why is that? To me this does not make sense.BTW: I do not want to cause extra complexity. We can also stay with the approach that the native matrix OS build is already building the full package and target release. However, then before we would need to build things like the documentation first and then include that single documentation into all the matrix os builds (via maven repo? or via GHA uploads/downloads). I just have the impression that this will all make it much more in-transparent and therefore complex. Currently, I do not fully understand what is going on and I would consider myself as a maven expert. So who will then be able to understand it and is capable to improve and apply fixes in the future? So we should find a simple and understandable solution and for what remains complex we should add documentation (e.g. comments or even asciidoc file explaining how all works together with GHA, maven, assembly, etc.).
And the most simple approach would be to build everything on the same node/VM. However, since GraalVM does not support cross-compiling, we can only build native-image for Mac on a MacOS machine and the same for Linux and Windows. Therefore my vision is that the main build is doing all OS independent stuff (doc, build JARs, run tests, etc.) and this only delegates the native image build on the other machines. It is IMHO acceptable if those matrix OS builds all compile the Java code redundantly but building the documentation 3,4,.. times with different timestamps on the front-page, etc. or esp. running the JUnits redundantly for each OS/arch seems like waste and very odd. Otherwise we could even have done the full build redundantly on each OS but the problem with this simple approach is that we cannot tag git and create github releases redundantly and if then one OS succeeds and the other fails, we end up with a partial release that is published but incomplete.