Dune-release workflow when CI fails

I’m exploring dune-release to submit some of my code that is hosted on GitHub to the opam repository. I can get the point where I submit a pull request on opam-repository but what is the correct workflow when the opam-repository CI fails and I need to make changes - most likely to the opam file and update my pull request?

If you need to change only the opam files (e.g. adding lower bounds / platform incompatibilities), then you can do this directly in your opam-repository fork and push to the PRed release branch as normal. Fortunately, there’s no need to re-cut the release just to fix this metadata. (The Opam maintainers tirelessly make such fixes on my release PRs all the time.)

If you do need to make some changes to the actual distribution, you’ll need to purge the GitHub release and then re-start the dune-release process up to the point of creating a PR (at which point you can just re-use the existing PR branch and force-push to that). To my knowledge, dune-release has no first-class support for this, though it might be a good feature request.

3 Likes

The opam file is indeed in the top commit of my opam-repository.git and I could modify that. But this somehow breaks the abstraction that dune-release tries to provide. (I also learned that one probably should put version constraints on almost all dependencies to avoid the CI failure; the downside is that this almost certainly will make constraints harder than necessary.)