search

dotCMS / core

Headless/Hybrid Content Management System for Enterprises
http://dotcms.com
Other
857 stars 467 forks source link

Configure packagers and distributions over dotcms-cli release process #26500

Closed dcolina closed 10 months ago

dcolina commented 11 months ago

Following the Quarkus approach we have to build the different packages to distribute the cli application.

It's very important to consider the current release process (through JReleaser) is taking the generated *-runner.jar” renaming it without the -runner and this is what we see packaged in the GitHub release. This is actually runnable with java -jar so this may be good in this respect, This will not work with other release locations as I think homebrew for example will expect the artifact to be able to executable directly on the platform and is not going to manage running with java. Note how in the assets for the releases in Quarkus, they do not distribute the cli jar directly but through the zip template contining the runner jar and script to run as well as license.

Other considerations

On the Quarkus cli instructions you can install a particular version of the cli with

jbang app install --name qs2.2.5 io.quarkus:quarkus-cli:2.2.5.Final:runner

This is just pointing directly to the runner jar in maven central. This does not use the jbang catalog. The jbang catalog is only being used as a way to automatically reference the latest release version.

Since jreleaser is not handling jbang at all in this case, we have to:

  1. Using maven deploy to deploy cli module containing core jar and -runner jar.

  2. On release update jbang catalog to point directly at last release runner jar.

  3. Use jreleaser to create a distribution zip package containing runner and wrapper scripts and deliver to github, brew, sdkman and chocolaty with the JAVA_BINARY type. it specifies the wrapper script name in bin folder “qurakus” and windows extension “.bat”

Now the update to jbang catalog can point to our artifactory release if we follow their mechanism and just specify the full public url to the runner. But the example pointing to specific maven “io.quarkus:quarkus-cli:2.2.5.Final:runner” would not work without being told about the artifactory repository or published to maven central.

Interesting links

quarkus-release (Readme) publish-cli.sh release-cli.sh java-binary update-jbang-catalog.sh

dcolina commented 10 months ago

Regarding this task, it is necessary to note the following: the defined release process requires the creation of distribution packages for each of the supported platforms (macOS-x86_64, macOS-arm64, linux-amd64). These distributions are the native executables created after compilation with Graal.

The main limitation we have found is that for the aarch64 architecture (MacOS silicon) we have not been able to generate a functional executable from a local environment, which leads us to change the approach and therefore we have to try to generate it through a Github workflow.

Another limitation or difficulty that we have found is to effectively test the distribution generated for the Linux architecture, since our local environment is MacOS (silicon), for such reason this would imply the use of emulators or looking for different alternatives that make the complexion difficult.

Since there are several objectives and the scope of this task is very broad, we decided to create more specific tasks that allow us to address the objectives in a more concrete way with a more detailed scope and thus be much more agile in achieving the objectives.

Task 26917 Task 26918