Respect dev-repo argument when publishing releases - #522
Merged
Conversation
Leonidas-from-XIV
self-requested a review
August 11, 2026 07:27
The release publication workflow was not respecting a configured dev-repo, instead always deriving the repo to release on from the opam file. This is fixed by relating the derivation of the repo info a supplied `dev_repo` value, when the latter is given. If the dev repo is not given, we fallback to the old behavior, if it is, we use this value to derive the repo information which is eventually used for the API call to publish the release to github.
Leonidas-from-XIV
force-pushed
the
respect-dev-repo
branch
from
August 11, 2026 08:19
b35666e to
0133da7
Compare
Leonidas-from-XIV
approved these changes
Aug 11, 2026
Leonidas-from-XIV
left a comment
Member
There was a problem hiding this comment.
I've rebased on main to update the changelog and pick up the new formatter version. Looks good to me.
I agree that the tests can't be really used that much when dealing with Github interaction since there isn't a good separation between computation and network interaction. But this looks simple and sensible enough.
Member
Author
|
Thanks for the rebase and confirmation about the testing! I'll run some tests on my machine today confirm its working as expected and report back :) |
Member
Author
|
Manual testing on by fork of dune-release worked as expected: producing
I am happy to have this merged. Thanks for the review and the cleanup refactor with the helper function too :) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #521
The release publication workflow was not respecting a configured dev-repo, instead always deriving the repo to release on from the opam file.
This is fixed by relating the derivation of the repo info a supplied
dev_repovalue, when the latter is given. If the dev repo is not given, we fallback to the old behavior, if it is, we use this value to derive the repo information which is eventually used for the API call to publish the release to github.I made a go at adding tests, but soon discovered that the code does not seem suitably organized to support testing these parts of the logic: they cannot be exercised by cram tests with
--dry-runbecause--dry-runlogic skips non-mutating observation of the system, such as reading the opam file (https://github.com/shonfeder/dune-release/blob/respect-dev-repo/lib/opam.ml#L220) and it cannot be exercised in unit tests, since the pure core of the computations is not isolated from the effecting execution logic.If there is already a known strategy for adding tests for these kinds of changes, a pointer would be welcome.
cc @Leonidas-from-XIV