Create Latest Release for Every Merged Pull Request

[dnestoro]

What does this PR do?

This PR enables automatic latest releases. Whenever a new metadata is merged, we will update current latest tag (delete previous and create a new one) to contain that metadata.

To make this work, we must create initial latest tag with the corresponding release. Otherwise attempt to delete previous release will fail.

[dnestoro]

This additional step skips latest tag as potential base for next standard release tag name (as we always bump patch version in the version string, we want to do so from the latest standard release).

[vjovanov]

Maybe write that comment in the file?

[fniephaus]

Why is this needed? Are you sure latest is even an accepted value for the version string? If we need more frequent releases, I'd vote for increasing the number of builds per month, for example to once every week.

[dnestoro]

Why is this needed? Are you sure latest is even an accepted value for the version string? If we need more frequent releases, I'd vote for increasing the number of builds per month, for example to once every week.

This kind of release can give users multiple benefits. For example:

• Users don't need to wait two weeks to be able to use their metadata
• Also users may want always new metadata in their projects in the development
• Besides that if we make releases too frequent (weekly or even more frequent) we may unnecessarily spend github resources for storing many releases with just 1-2 libraries difference

For the latest as a version string I am not sure. I tried it on a testing repo and Github accepts it. We can discuss a different name for this kind of releases. Maybe we can use something with SNAPSHOT annotation (or even only SNAPSHOT)?

[fniephaus]

If someone wants to you the latest metadata, wouldn't it be better if the consumer, the thing that downloads the metadata, uses this link rather than a latest tag that we need to manage manually: https://github.com/oracle/graalvm-reachability-metadata/archive/refs/heads/master.zip

[melix]

So I think having a head/master/snapshot release is indeed useful. For example a user can download the archive and add it to their sources, then configure the plugin to use that zip.

The question that Fabio raises is whether we actually need to do that, given that there's already something similar provided out of the box by GitHub. The difference is that the content of the zip file is different: a metadata release contains directly, at the root of the zip file, the content of the metadata directory only (the rest of the repository is irrelevant for users). The zip provided by GitHub contains a top level directory named graalvm-reachability-metadata-master then the whole repository. Therefore it cannot be exploited directly by the user (or the plugins).

[vjovanov]

I would call it graalvm-reachability-metadata-SNAPSHOT.zip, as this is what is the maven community uses. Since we are providing this for the JVM I feel it would immediately ring a bell to all the users.

[vjovanov]

Missing line

[vjovanov]

LGTM