Release workflow

[Halbaroth]

This PR adds a release workflow that build an artefact with dune-release.

The workflow runs only on branch v*.*.x.

Should be tested on the branch v2.5.x.

[bclement-ocp]

Maybe this could replace the make_release job in build.yml?

I think this should be run on push to the v branches, not only pull_request.

Can we try the workflow on this PR by either making it target v2.5.x or by temporarily making the workflow target any pull requests (just for testing the workflow)?

[bclement-ocp]

I don't think this has run? I believe it needs the pull_request permission

[Halbaroth]

Actually, I did the test on my repository. The workflow failed just because there is no tag on my branch and dune-release needs a tag. I will fix the issue later but I am working on the paper for the tomorrow.

[bclement-ocp]

OK, no worries, I just got there from the GH notifications. I don't think we should spend too much time on this — it would be useful, but if it's complicated ("dune-release needs a tag" looks like it's going to be brittle to do it in the CI :/ ) we should drop it, as we discussed last week.

[Halbaroth]

I think we can do it by matching tag instead of branch in the on clause. In such way, we are absolutely sure the workflow will run only on tagged branch but we have to clear tags on the next branch, otherwise the workflow will run all the time on this branch also. I will finish that later.

[bclement-ocp]

Clearing tags on an existing repo is not a good idea, should be to be (mostly) immutable. If dune-release insists on having a tag, it would be better to run the workflow when pushing tags instead (I think this is supported?).

Edit: Apologies, I misread -- this is exactly what you are suggesting. I don't think the workflow would run on existing tags so there should be no need to clear them.

[bclement-ocp]

That said, if we need a tag, it's not really useful to run this on the CI, because it means publishing the tag before testing the release, which defeats the whole purpose of testing prior to the release.

[Halbaroth]

According to the dune-release documentation the command dune-release distrib uses the HEAD of the current branch to construct the tarball:

Now that the release is tagged in your VCS, generate a distribution archive for it in the build directory with:

dune-release distrib

This uses the source tree of the HEAD commit for creating a distribution in the build directory. Note that any uncommitted change will therefore be ignored. The distribution version string is the VCS tag description (e.g. git-describe) of the HEAD commit. Alternatively it can be specified on the command line.

Basic checks are performed on the distribution archive when it is created, but save time by catching errors early. Hence test that your source repository lints and that it builds in the current build environment and that the package tests pass.

We can rename the artifact with the commit number for instance. As we have at least one tag accessible from the branch v2.5.x, the command dune-release distrib won't fail.

EDIT: we could also suggest a new CLI option on the dune-release repository but the workflow will work without any modification in dune-release.

[bclement-ocp]

The distribution version string is the VCS tag description (e.g. git-describe) of the HEAD commit. Alternatively it can be specified on the command line.

Looks like this may already be there?

[Halbaroth]

The distribution version string is the VCS tag description (e.g. git-describe) of the HEAD commit. Alternatively it can be specified on the command line.

Looks like this may already be there?

You can choose a tag but you cannot create a fake tag with this command.

[Halbaroth]

I checked that dune-release uses the HEAD to build the tarball. If the HEAD is not a tag, the software adds the number of the hash of the current commit after the name of the last tag on the branch. We don't even need to modify the name to get the appropriate behaviour!

As I explained offline, the workflow failed as custom licenses are not supported by opam < 2.2. As the version of opam is still 2.1.5 in ocaml-setup, the linter of opam failed. We will wait for an update of ocaml-setup to test again and merge this PR.

[Halbaroth]

Good news everyone :D!

A new flag to use the pre-release of opam will be merged soon into the setup-ocaml action, see ocaml/setup-ocaml#704.

[Halbaroth]

It works as you can check here: https://github.com/Halbaroth/alt-ergo/actions/runs/7048354867 :)

[bclement-ocp]

Should we maybe use workflow_dispatch and run the workflow manually instead of automatically? We may not want to run it on all commits of release branches (since there can be a bit of back-and-forth after branching and before the release is ready).

[Halbaroth]

Sure :)

[bclement-ocp]

Nit: Apologies, I forgot about this earlier — it'd be safer to use 4.14 for this, given that this is what we test and bench on. Although it should not matter too much since this is just for building the release archive.