Add support for nightly builds for dev branch
#3247
Conversation
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
- 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 |
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.
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.