Configure rolling releases

[aalmiray]

Issue

Configures rolling releases on every push to master branch.
Configures final release on workflow dispatch (manual trigger)

Rolling releases publish binaries only as Git release assets.
Final release additionally publishes binaries to S3.

Fixes #446

Progress

• Change must not contain extraneous whitespace
• License header year is updated, if required
• Verify the contributor has signed Gluon Individual Contributor License Agreement (CLA)

[aalmiray]

Converting to draft as JReleaser 1.0.0-M1 is needed.

[AlmasB]

Many thanks for this. I've skimmed through to get a rough idea and left some questions, but I don't have the required SB build / release expertise, so I'm tagging @jperedadnr and @abhinayagarwal

Once this is ready and merged, we should have a much quicker response iteration between the dev team and the users.

[abhinayagarwal]

I did an initial overview of the PR. Overall, its great work. Thank you @aalmiray for taking the time.

Here are my initial thoughts & questions on the PR:

• It would be nice if we could also upload the final release artifacts to homebrew, snap etc. using JReleaser. May be something for a follow-up PR
• Github's limitation of uploading all artifacts in a single ZIP can be frustrating for a user, as they would have to download all the artifacts when their intention would be to just test one of them
• Artifacts are uploaded from individual OS specific workflows. What exactly is JReleaser doing in early-access workflow?
• We might want to replace TAG keyword with something else as we no longer do releases via TAG. Does JReleaser pushes a TAG to the repository after a release?

[aalmiray]

It would be nice if we could also upload the final release artifacts to homebrew, snap etc. using JReleaser. May be something for a follow-up PR

Homebrew can be added easily however be aware that this is via a tap repository under your control and not a core formula.

Other packagers such as Snap, Chocolatey, etc are not yet supported. That's something I can have a look at.

Github's limitation of uploading all artifacts in a single ZIP can be frustrating for a user, as they would have to download all the artifacts when their intention would be to just test one of them

Only if they download artifacts from the GH workflow download area which is not ideal, that's one of the reasons for crafting early access releases, which answers the next question

Artifacts are uploaded from individual OS specific workflows. What exactly is JReleaser doing in early-access workflow?

JReleaser tags, creates a Git release with changelog, uploads all artifacts as release assets alongside their checksums.

We might want to replace TAG keyword with something else as we no longer do releases via TAG. Does JReleaser pushes a TAG to the repository after a release?

Right. TAG is akin to the project version while VERSION is akin to the app version used by jpackage. Right now both the project version and the git tag match while the app version differs as it can't contain elements such as -RC or -SNAPSHOT.
Yes, JReleaser can create and push the tag however for the release workflow I configured the Maven release plugin to make that happen as it does 2 things: bump version to release, tag, and push changes.

[aalmiray]

Force pushed the following changes:

• fixed repository coords in pom.xml as noted by @AlmasB
• removed comments on features from JReleaser 1.0.0-M1, We're almost there.
• Added homebrew per @abhinayagarwal's suggestion

Note that a new secret named GITHUB_ACCESS_TOKEN is required. this is a personal access token that can read/write to repositories on the gluonhq organization. Required to push the brew cask to gluonhq/homebre-tap which will be created for you by JReleaser. Refer to https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token

[aalmiray]

@abhinayagarwal filed the following:

• [snap] Support native package distributions jreleaser/jreleaser#682
• [macports] Support native package distributions jreleaser/jreleaser#684
• [chocolatey] Support native package distributions  jreleaser/jreleaser#685

[aalmiray]

PR is ready for review.

Package managers such as Homebrew, Macports, Chocolatey, Snap have been disabled as they require additional setup such as service accounts and API keys. We can discuss which package managers should be enabled and their requirements.

For the time being this PR will enable rolling releases on every push to the master branch.

[abhinayagarwal]

Right. TAG is akin to the project version while VERSION is akin to the app version used by jpackage. Right now both the project version and the git tag match while the app version differs as it can't contain elements such as -RC or -SNAPSHOT.

That's correct difference b/w TAG and VERSION. jpackage doesn't support -RC or -SNAPSHOT in version.

My initial concern was in case of early-access, we still use TAG, which is coming from previous workflows. However, since there is no tag involved, we may want to rename it to PROJECT_VERSION ? And subsequently, VERSION to APP_VERSION ?

[aalmiray]

OK but be aware that changes to the jpackage scripts are also required as they expect VERSION.

[aalmiray]

I'd recommend squashing commits when merging this PR.

[AlmasB]

Yes, squash and merge is the default option for this repo.

[abhinayagarwal]

Hi @aalmiray ,

As suggested, I tried adding GITHUB_ACCESS_TOKEN to the list of secrets. However, it failed with the following message:

Failed to add secret. Secret names must not start with GITHUB_.

P.S. We generally use PAT as the keyword in other repositories where personal access token is required.

[aalmiray]

Oops you are right. I used GIT_ACCESS_TOKEN in my repos. Will change to PAT.

[abhinayagarwal]

@gluon-bot's PAT added as a secret

[aalmiray]

Looks like early-access.yml#L99 must be deleted. I missed it.

The bundle-kit.yml workflow does not have an "app-version" input.