Closed arbourd closed 1 month ago
On the unitctl/x.y.z
tag namespace... Do we want to have distinct versioning for unitctl, or do we want to bind its version to Unit releases?
To echo Dan's sentiments.
We have tags depicting Unit releases. Do we want to pollute that with other tags?.
Is there a very good reason not to just tie it off Unit releases?.
I.e I expect to see (and I don't know if we have tooling that expects the same)
$ git describe
1.32.0-72-g5d1ce5c4
The only thing you could do is use a lightweight tag, but that's not really correct as they aren't supposed to be distributed (although we do use them for the packaging tags), but I think you need a really good reason for it to have its own tags.
I am happy to tie it to unit releases. Currently testing a patch to do just that.
What was the rush?
This should have been committed as a single commit.
We don't commit things in a known broken/incorrect/intermediary state immediately followed by fix up commits...
Adds a GitHub Actions workflow that builds and releases unitctl binaries when a tag prefixed with
unitctl/
is pushed.Binaries are built on pull-requests that change any files within
tools/unitctl
, onmaster
branch pushes and whenunitctl/
prefixed tags are pushed.