gha/release: Improve workflow input descriptions and ordering#307
gha/release: Improve workflow input descriptions and ordering#307vvoland merged 2 commits intodocker:mainfrom
Conversation
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
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>
rumpl
left a comment
rumpl
left a comment
There was a problem hiding this comment.
Sure, but I still don't quite understand what "Release type" means
vvoland
force-pushed
the
distros-optional
branch
from
d630cfa to
d02efe7
Compare
|
Yeah just updated it |
thaJeztah
left a comment
thaJeztah
left a comment
There was a problem hiding this comment.
Just spitballing some ideas 🤗
| inputs: | ||
| ref: | ||
| description: 'Ref (e.g. v0.10.0)' | ||
| description: 'Tag/ref to build (e.g. v0.10.0)' |
There was a problem hiding this comment.
| 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 describeformat likely as well (e.g.api/v1.52.0-beta.3-36-g5680867af8)
There was a problem hiding this comment.
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' |
There was a problem hiding this comment.
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
- ...There was a problem hiding this comment.
Github doesn't render newlines/lists nicely in the workflow popup, so that would bloat the window too much I think:
| description: '(optional) Release type to create in https://github.com/docker/packaging/releases' | ||
| required: false | ||
| default: 'pushonly' | ||
| default: 'draft' |
There was a problem hiding this comment.
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?)
There was a problem hiding this comment.
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.
| description: '(optional, empty = all supported) Distros to build (comma-separated, e.g. "debian12,ubuntu2204")' | ||
| required: false | ||
| type: string | ||
| default: '' |
There was a problem hiding this comment.
Wondering how long the list is, and if we could have / generate a checkbox-list for this 🤔
There was a problem hiding this comment.
We should get rid of it after this one is merged: https://github.com/docker/release-repo/pull/727
5 participants
No description provided.