Add support for nightly builds for dev branch#3247
Open
Conversation
- Use matrices for building on separate platforms - Add support for (dev branch) nightly builds on which update the release (with 'nightly' tag). If no changes have been made to dev, then no changes are made.
Lestropie
reviewed
Dec 16, 2025
Member
|
Very tough to review only from code. Demonstrated generation of releases: https://github.com/daljit46/mrtrix3/releases/tag/nightly What's the lifetime of the generated release assets? In #2665 @tclose is looking for persistent build derivatives. I don't particularly want to generate a pre-release tag as the code is a long way away from being "pre-release", but if nightly |
Lestropie
reviewed
Dec 16, 2025
Lestropie
reviewed
Dec 16, 2025
Member
|
CLI works, but mrview produces: |
Member
|
What I noticed is that the directory naming scheme is not the same across platforms, e.g. on macOS it unpacks to |
Co-authored-by: Robert Smith <robert.smith@florey.edu.au>
Co-authored-by: Robert Smith <robert.smith@florey.edu.au>
Member
Author
The workflow deliberately deletes old release artefacts on a new nightly run. This is primarily to avoid wasting storage space. If the intention is to use the latest release asset as the build derivatives, then this is fairly straightforward, as the URL for the assets will always point to the latest ones (as long as the name of the artefacts is not changed). One can even query more robustly via |
Member
Author
|
@MRtrix3/mrtrix3-devs One issue that needs to be solved prior to this is our version matching logic in FindVersion.cmake. Since the new workflow relies on the existence of the |
Member
|
It might be necessary to have a more verbose name than Indeed there could be a
Maybe safer would be requiring that a cmake variable be defined at the command-line indicating that the intended tag is
It will presumably still show in the verbose description that there are a large number of commits between the most recent tag and the tip. But true, it's not the most interpretable thing in the world. Maybe as a resolution to both this and request in #2665 we could create an "alpha" tag (which I find more palatable than "release candidate") on |
Member
Author
I think generally speaking (in other software projects), "nightly" releases are not intended to be bug fixes. They usually refer to releases of the branch where new features for the software are actively being developed (in our case,
I've implemented this on my fork of MRtrix3, with a new |
Member
|
Just checked the latest release artefacts on Daljit's repo, and the version string issue is resolved (base tag still shows up as Naming-wise, I'd be happy with a But ultimately, I don't think the name of the tag itself is the issue (it makes a very minor hard-to-spot appearance as the tag on the release page), what matters more is the description shown as the title on the GitHub Release page (currently reads "MRtrix3 Nightly Release" on Daljit's repo). And since the workflow recycles the release (as I understand it), we can set that title however we want and (I assume) modify it later if appropriate (please correct me if I've got that wrong!). I'd advocate for something like "MRtrix3 nightly build (dev branch)" (not sure 'latest' would work instead of 'nightly' here - some users might assume this is the latest release). And add a bit more to the description to make it clear that this is not an official release, but provides a build of the latest version of the code as it stands to allow testing, etc. Once merged to The version string shown with the |
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
4 participants
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.
This PR refactors the
releases.ymlworkflow to add support for nightly builds for thedevbranch. The workflow is scheduled to run every day at00:00and will update the release tagged with thenightlytag (which I have already created) with the artefacts for each platform. The release will show the latest 15 commits ondev. If there have been no changes ondevsince the last run, the workflow is cancelled.Additionally, the workflow file has been refactored for improved code reuse and a simplified YAML file that utilises the GitHub Actions matrix strategy to build artefacts for each platform.