Skip to content

Conversation

@vvoland
Copy link
Collaborator

@vvoland vvoland commented Oct 31, 2025

No description provided.

Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
@vvoland vvoland self-assigned this Oct 31, 2025
@vvoland vvoland requested a review from a team as a code owner October 31, 2025 14:56
@vvoland vvoland requested review from glours and rumpl October 31, 2025 14:56
Copy link
Contributor

@glours glours left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

The majority of runs are no longer test-only so I think it's fine to
have a draft already in place that can be easily turned into a real
github release.

Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Copy link
Member

@rumpl rumpl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but I still don't quite understand what "Release type" means

@vvoland
Copy link
Collaborator Author

vvoland commented Oct 31, 2025

Yeah just updated it

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just spitballing some ideas 🤗

inputs:
ref:
description: 'Ref (e.g. v0.10.0)'
description: 'Tag/ref to build (e.g. v0.10.0)'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
description: 'Tag/ref to build (e.g. v0.10.0)'
description: 'Tag or git reference to build from (e.g. v0.10.0)'

Can we provide a valid non-tag example? I think this would also accept;

  • branch name
  • maybe refs/xx/xx/ (we could have a PR ref as example)
  • git sha
  • git describe format likely as well (e.g. api/v1.52.0-beta.3-36-g5680867af8)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't encourage non-tag usage right now, as the VERSION string is derived from the reference.

So until we have an option to override the visible version (see #260) I wouldn't want to provide other examples than tags.

type: string
release:
description: 'Release type'
description: '(optional) Release type to create in https://github.com/docker/packaging/releases'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps a multi-line text block to also outline what the different options do;

- `pushonly` pushes the artifacts as an image, but does not create a (draft) release.
- `draft` pushes the artifacts as an image, and creates a draft release in  https://github.com/docker/packaging/releases
- ...

Copy link
Collaborator Author

@vvoland vvoland Oct 31, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Github doesn't render newlines/lists nicely in the workflow popup, so that would bloat the window too much I think:

image

description: '(optional) Release type to create in https://github.com/docker/packaging/releases'
required: false
default: 'pushonly'
default: 'draft'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With a better description, do we perhaps want the default to be be kept pushonly? That makes it more of an explicit choice to decide what you want to do.

And .... maybe make that a required: true (need to pick something); is that possible with a choice? (does it have a none option?)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was fine when testing, but now 99% cases you actually trigger it is for the actual deploy.

You can always delete the draft afterwards, but you can't easily regenerate the release if you do it as pushonly.

Comment on lines +25 to 28
description: '(optional, empty = all supported) Distros to build (comma-separated, e.g. "debian12,ubuntu2204")'
required: false
type: string
default: ''
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering how long the list is, and if we could have / generate a checkbox-list for this 🤔

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should get rid of it after this one is merged: https://github.com/docker/release-repo/pull/727

@vvoland vvoland merged commit 7630f2c into docker:main Nov 4, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants