-
Notifications
You must be signed in to change notification settings - Fork 37
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
chore: workflow dispatch releases #161
Conversation
commit:
|
.github/workflows/ci.yml
Outdated
workflow_dispatch: | ||
inputs: | ||
version: | ||
description: "type of ref" | ||
required: true | ||
type: choice | ||
options: | ||
- patch | ||
- minor | ||
- major | ||
default: "patch" |
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.
Instead of doing this with a workflow dispatch, I think it is better to do a scheme like we have in Vite. We have a release script that bumps the version in main and commits that (together with the changelog but not needed here if you don't want) and tags that commit with vX.Y.Z
. And then we have an github workflow that publishes each tag that matches that format. See https://github.com/vitejs/vite/blob/main/.github/workflows/publish.yml (we also have another workflow that does a github release on listening to the same event, but that is also not necessary if you don't want). This is a easier flow because you directly release from your CLI with a commit and every published commit is clearly marked in GitHub with a tag.
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.
Yea I was inspired by vite's workflow, and more importantly, the vite-ecosystem-ci workflow!
To be honest, I think publishing from workflow_dispatches, exactly next to cloudflare deploys would be way better. And then we can create tags (i'll add it in next commits then, I agree).
what do you think?
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 think it is better to release from a tag instead like we do in Vite because then you force yourself to only publish properly tagged versions. I think it is useful to have this tagged commit also be the one that is doing the bump. So all is connected.
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 see, you mean just a git push origin tag v0.0.18
would trigger a release?
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.
where would the change of the package.json version would be handled?
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.
Hmm, I think we can do that but don't we block direct pushes to main?
So we cannot do things with one command alone. Wdyt?
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 can unblock direct pushes to main if that is an issue. We would still have the approval flow to decide if that push will end up or not published, so it is fine.
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 pushed a new commit, let me know what you think.
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'm good with this if vite releases works for you. It is very opinionated for the packages in the Vite repo, so probably better to use something more common, but let's go with this for now.
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.
yea it works for our case, not heavily tested though since we need to try all the workflow in the main branch.
No description provided.