differentiate unitctl releases

[avahahn]

• title of release is modified to read "unitctl-..."
• body text added to elaborate that this is only a release for unitctl
• explanation added for where users can find releases of Unit itself

Example release: manual trigger: https://github.com/avahahn/unit/releases/tag/999.1.2-thebeesknees tag trigger: https://github.com/avahahn/unit/releases/tag/9.9.10

[ac000]

Can we clear this up once and for all!?

https://github.com/nginx/homebrew-unit/issues/39#issuecomment-2113815977

[callahad]

Perhaps more explicitly: it looks like your test fork is creating tags for manual runs of the workflow. Is it possible to do a GitHub release without making a tag?

[callahad]

From some initial searching, it looks like a tag is required for published releases and prereleases, but it may be possible to ship a draft release without actually creating a tag in the repo (draft: true in the release-action parameters) until that draft is published.

It's not clear to me who is able to see draft releases.

If I'm grokking correctly, it seems like our options for pushing artifacts outside of a full Unit release are:

1. Use draft releases, but they're likely only visible to repo collaborators, or
2. Create new tags

Does that seem like a correct assessment?

Is there something I'm missing? (e.g., can we delete the tag after making the release?)

[ac000]

Hmm, it does seem that way...

I thought it worked the other way around, i.e a release would be triggered on a tag being pushed.

Is there something I'm missing? (e.g., can we delete the tag after making the release?)

Creating and deleting a tag could be OK, especially if it's a lightweight tag. However the main issue there would be that you'd be stuck trying to checkout that version from git, if for example you wanted to attempt a reproducible build or any of a myriad of other reasons.

However having stumbled across

I believe that creating a release from the GitHub web UI also triggers a tag push, as long as the tag didn't already exist.

Perhaps that's the way to go... doing that after a Unit version tag is pushed shouldn't result in any new tag (or tag update).

[callahad]

I thought it worked the other way around, i.e a release would be triggered on a tag being pushed.

The release step also triggers on that case.

  release:
    if: startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch'

So the release step happens whenever we push a tag matching '[0-9]+.[0-9]+.[0-9]+', or when we manually invoke the workflow.

[ac000]

So the release step happens whenever we push a tag matching '[0-9]+.[0-9]+.[0-9]+', or when we manually invoke the workflow.

Yeah, that's what I thought... so if we want to do a manual release now we just 'back date it' to 1.32.0/1 and it shouldn't do any harm...

[callahad]

Can we backdate it to an existing tag, or would that also try to build with the source as of that tag (and in which unitctl doesn't exist?)

[ac000]

Good point! bit of a chicken & the egg problem...

[ac000]

On Thu, 16 May 2024 16:18:14 -0700 avahahn @.***> wrote:

From some initial searching, it looks like a tag is required for published releases and prereleases, but it may be possible to ship a draft release without actually creating a tag in the repo (draft: true in the release-action parameters) until that draft is published.

Did you not see the linked example releases? The manual release is not done with any kind of tag. We do not need to worry about this.

There is certainly some amount of confusion around this...

I see your manually released unitctl and it has a tag of 999.1.2-thebeesknees

I pulled your repository and I see that tag in there as a lightweight tag. It points to one of my commits

$ git show 999.1.2-thebeesknees commit 30b39bd0776bf00de20ea7410ae54fbb85a64c58 (tag: 999.999.999-yeehaw, tag: 999.1.2-thebeesknees, tag: 19.19.19-testing123, tag: 1.999.999-2, tag: 1.33.2-test, tag: 1.22.44-test3) Author: Andrew Clayton @.***> Date: Fri Apr 19 19:09:59 2024 +0100

Add GitHub workflows for extra coverage

So things are not entirely clear to me.

Did you create that tag to trigger a release?

But from your PR message

manual trigger: https://github.com/avahahn/unit/releases/tag/999.1.2-thebeesknees tag trigger: https://github.com/avahahn/unit/releases/tag/9.9.10

"manual trigger" as opposed to "tag trigger" would indicate not.

Or was it just a tag you created so there was a tag associated with the release?

Perhaps you could give a description of how this process actually works?

[avahahn]

Or was it just a tag you created so there was a tag associated with the release?

It was made automatically by the release action it seems

Perhaps you could give a description of how this process actually works?

Heres the code: https://github.com/ncipollo/release-action/tree/main/src I dug as deep as the octokit core library and couldnt find the logical case where this thing is actually generated. I think github is a closed source application.

[avahahn]

@ac000 @callahad

What is the path forward for this changeset?

[callahad]

@avahahn The next step is for you to propose what we do about tagging. :)

The original discussions were predicated on being able to generate releases without creating tags. It appears that is not possible per my comment above.

The simplest thing is probably namespacing the tags with a unitctl/ prefix, but I honestly don't care what we decide so long as it's considered and deliberate.

[avahahn]

@avahahn The next step is for you to propose what we do about tagging. :)

The original discussions were predicated on being able to generate releases without creating tags. It appears that is not possible per https://github.com/nginx/unit/pull/1265#issuecomment-2115052043.

The simplest thing is probably namespacing the tags with a unitctl/ prefix, but I honestly don't care what we decide so long as it's considered and deliberate.

I think in this case the most effective thing we can do is to use namespaced tags when we trigger manual releases and try to minimize their use. I think we could use a namespaced tag in the here and now to cut the first release, but then rely on normal tags being pushed to the repo during the release process to cut future github releases.

[ac000]

Can that be created as a lightweight tag so it doesn't interfere with the likes of git-describe(1)?

[avahahn]

There is certainly some amount of confusion around this...

I see your manually released unitctl and it has a tag of 999.1.2-thebeesknees

I pulled your repository and I see that tag in there as a lightweight tag. It points to one of my commits

If your observation is correct, then this it is in fact created as a lightweight tag. Then we can assume that tags created by the action during manual triggers are lightweight

[ac000]

To be honest I'm too uneasy with this whole concept that it wouldn't be appropriate for me to approve this...

[callahad]

Social agreement: Don't manually run the workflow without talking to the team first.

(I'll write down a full characterization of the impact on git describe for manual and automatic runs of the workflow beforehand)

[callahad]

Manually running the workflow does not create annotated tags, so git describe is unaffected.

Here's a full shell session showing how things work

$ gh repo clone callahad/unit-tmp && cd unit-tmp
Cloning into 'unit-tmp'...
remote: Enumerating objects: 20904, done.
remote: Counting objects: 100% (568/568), done.
remote: Compressing objects: 100% (322/322), done.
remote: Total 20904 (delta 271), reused 409 (delta 206), pack-reused 20336
Receiving objects: 100% (20904/20904), 12.24 MiB | 10.06 MiB/s, done.
Resolving deltas: 100% (15444/15444), done.
From github.com:nginx/unit
 * [new branch]        master     -> upstream/master

$ git describe
1.32.0-130-g57a0f94e

$ gh workflow run unitctl -f version=1.32.0-unitctl.a
✓ Created workflow_dispatch event for unitctl.yml at master

To see runs for this workflow, try: gh run list --workflow=unitctl.yml

$ git pull --tags
From github.com:callahad/unit-tmp
 * [new tag]           1.32.0-unitctl.a -> 1.32.0-unitctl.a
Already up to date.

$ git describe
1.32.0-130-g57a0f94e

$ git switch -d 1.32.0-unitctl.a
HEAD is now at 57a0f94e tools/unitctl: unitctl export

$ git describe
1.32.0-130-g57a0f94e

$ echo "foo" >> README.md && git commit -am 'test commit'
[detached HEAD c100a413] test commit
 1 file changed, 1 insertion(+)

$ git describe
1.32.0-131-gc100a413

(cc: @ac000)

[callahad]

Note: I would've expected the created tag to be unitctl/1.32.0-unitctl.a - that's a bug in this PR. Separate PR coming to address that.

[ac000]

What's the .a mean? and do we need unitctl in there twice?

[callahad]

That's just me entering an arbitrary name during testing.

[ac000]

On Thu, 20 Jun 2024 04:56:57 -0700 Dan Callahan @.***> wrote:

Manually running the workflow does not create annotated tags, so git describe is unaffected.

Here's a full shell session showing how things work

$ gh repo clone callahad/unit-tmp && cd unit-tmp
Cloning into 'unit-tmp'...
remote: Enumerating objects: 20904, done.
remote: Counting objects: 100% (568/568), done.
remote: Compressing objects: 100% (322/322), done.
remote: Total 20904 (delta 271), reused 409 (delta 206), pack-reused 20336
Receiving objects: 100% (20904/20904), 12.24 MiB | 10.06 MiB/s, done.
Resolving deltas: 100% (15444/15444), done.
>From github.com:nginx/unit  
 * [new branch]        master     -> upstream/master

$ git describe
1.32.0-130-g57a0f94e

$ gh workflow run unitctl -f version=1.32.0-unitctl.a
✓ Created workflow_dispatch event for unitctl.yml at master

To see runs for this workflow, try: gh run list --workflow=unitctl.yml

$ git pull --tags
>From github.com:callahad/unit-tmp  
 * [new tag]           1.32.0-unitctl.a -> 1.32.0-unitctl.a
Already up to date.

$ git describe
1.32.0-130-g57a0f94e

$ git switch -d 1.32.0-unitctl.a
HEAD is now at 57a0f94e tools/unitctl: unitctl export

$ git describe
1.32.0-130-g57a0f94e

$ echo "foo" >> README.md && git commit -am 'test commit'
[detached HEAD c100a413] test commit
 1 file changed, 1 insertion(+)

$ git describe
1.32.0-131-gc100a413

(cc: @ac000)

Yes, it created a lightweight tag

$ git show 1.32.0-unitctl.a commit 57a0f94efb2550ea1c6cb593b2b968e022c89346 (tag: 1.32.0-unitctl.b, tag: 1.32.0-unitctl.a) Author: Ava Hahn @.***> Date: Tue Jun 18 23:06:05 2024 -0700

tools/unitctl: unitctl export

* new subcommand for "export" in CLI
* new cmd submodule for exporting config tarballs
* logic to also output to stdout
* README additions
* limitations documented

Signed-off-by: Ava Hahn ***@***.***>

As it's a direct reference to the commit and not a tag object...