Conversation
Vighnesh-V
force-pushed
the
lute-release-job
branch
3 times, most recently
from
6f5fbf4 to
04fcd71
Compare
Vighnesh-V
force-pushed
the
lute-release-job
branch
from
04fcd71 to
12fdb89
Compare
aatxe
left a comment
aatxe
left a comment
There was a problem hiding this comment.
Mostly looks good, but some comments.
.github/workflows/#shared-build.yml#
Outdated
| @@ -0,0 +1,136 @@ | |||
| name: _shared_release | |||
There was a problem hiding this comment.
This file is an editor artifact, right?
.github/workflows/.#shared-build.yml
Outdated
| @@ -0,0 +1 @@ | |||
| [email protected] No newline at end of file | |||
There was a problem hiding this comment.
Ditto about this being an editor artifact
| @@ -0,0 +1,140 @@ | |||
| name: _shared_release | |||
There was a problem hiding this comment.
Feel like this should probably be called shared-release then? Or maybe release-backend or something of that sort? shared-build feels a little odd since it does do release-specific workflow tasks, not just building the artifact.
There was a problem hiding this comment.
I think shared-release is a better name for this file!
|
|
||
| Lute uses branches with the format: `release/v{Major}.{Minor}.x` to store changes associated with a given release. | ||
| We tag commits with the format `v{Major}.{Minor}.{Patch}` to indicate that a commit should be build as that release version. | ||
| Changes like security updates, hotfixes, etc, occur on these branches and go through the code review process in order to be merged. |
There was a problem hiding this comment.
There's probably some nuance here. I think changes that would affect all future versions should probably always be against primary (or at least generally be?), with the idea that we'll, as maintainers, cherry-pick them to any supported release branches as-needed if there's a high degree of urgency. If the issue only exists in that version, then yeah, it should definitely just be against the version. I think a workflow that has most contributors mostly working against primary is probably the easiest to support.
2 participants
The job that will be used for automating releases and the job that will be used for nightlies share a lot of common actions. This PR separates the common chunk out into a re-usable workflow, called shared-build which is parameterized on the branch name.
In both cases the job will check out the branch and derive the tag name directly from the get_version.cmake command. If the branch is primary, we'll get 'nightly.YYYMMDD' appended.