Skip to content

Add periodic releases workflow#2835

Closed
daljit46 wants to merge 2 commits intomasterfrom
weekly_releases
Closed

Add periodic releases workflow#2835
daljit46 wants to merge 2 commits intomasterfrom
weekly_releases

Conversation

@daljit46
Copy link
Member

@daljit46 daljit46 commented Feb 29, 2024

This PR adds support for weekly releases. It provides a single workflow that builds and creates appropriate packages for each OS. Naming convention has been set to mrtrix3-OS-weekly-DATE-COMMIT.extension. Packages will be built for Linux, MacOS and Windows and released every Sunday at 12AM UTC time.
To enable this we need to create a new release tagged weekly which will be updated every week replacing the assets built the week before.

Tasks to be completed:

Needs to merged onto master because the workflow needs to run periodically, but it will the use dev branch to build the packages.

Feedback welcome.

@daljit46 daljit46 self-assigned this Feb 29, 2024
@daljit46 daljit46 marked this pull request as draft February 29, 2024 15:53
This will allow a developer to manually create a release for a given branch.
@daljit46
Copy link
Member Author

The workflow now supports a "branch" input that a developer can specify to build a release from a specific branch.
Still need to ensure that when a custom branch is used, the output is not a standard release but an artifact that can be downloaded via Github's web interface for actions.

@daljit46 daljit46 changed the title Add weekly releases workflow Add periodu releases workflow Jun 20, 2024
@daljit46 daljit46 changed the title Add periodu releases workflow Add periodic releases workflow Jun 20, 2024
@daljit46
Copy link
Member Author

daljit46 commented Jun 20, 2024

After thinking about this, I think it'd be better if we had one single release workflow that can handle:

  1. tagged releases
  2. weekly releases
  3. manually triggered releases that upload a GitHub Actions artifact rather than a release artifact

This will prevent code duplication in the CI code. One problem is that we want to test the workflows on master and dev. However, master is still on the old build system rather than CMake. To get around this, I think it's best to wait until master is also on CMake and incrementally implement the three features above.
What I would like to do is to first create a workflow on master that solely implements 3, so that we can test that build scripts are working as expected. Once we have master on CMake, we can implement and test 1 and 2.
Thus, I will be closing this PR and instead submit a new PR for 3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant