-
Notifications
You must be signed in to change notification settings - Fork 29
gha/release: Improve workflow input descriptions and ordering #307
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
glours
left a comment
There was a problem hiding this 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>
rumpl
left a comment
There was a problem hiding this 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
d630cfa to
d02efe7
Compare
|
Yeah just updated it |
thaJeztah
left a comment
There was a problem hiding this 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)' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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.
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' |
There was a problem hiding this comment.
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
- ...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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.
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?)
There was a problem hiding this comment.
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.
| 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.
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 🤔
There was a problem hiding this comment.
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

No description provided.