-
Notifications
You must be signed in to change notification settings - Fork 556
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
automate crate publishing #238
automate crate publishing #238
Conversation
This introduces a new section of the GitHub Actions workflow which will publish the crate upon a new tag being pushed. Note that this requires a new project secret, `CRATES_TOKEN`.
Pull Request Test Coverage Report for Build 191280814
💛 - Coveralls |
@nickolay or @andygrove, if one of you could add the |
@maxcountryman maybe could use some docs/instructions to describe how to publish (pushing with the right tags) |
I don't think I have the rights to do that. |
Yep--I wonder where best to keep that? |
@maxcountryman I've temporarily made you an admin on the repo |
Thanks @andygrove, I created a new token and added it to the repo secrets. I shouldn't need admin access any longer. |
Maybe a new file like |
Sure. I can add something to this PR. |
I noticed our tags are named slightly inconsistently. Does anyone have a strong preference or could be move towards omitting the |
Without v sounds good to me |
@nickolay can I just check you're all right with this methodology? I don't want to commit us to this process without everyone's buy-in. 🙂 |
Push-to-publish is great! Thanks! |
Thanks for pointing that out. @andygrove would you mind sharing the process/tool we should use for that? I can update the release doc accordingly. |
I've been using cargo release.
https://github.com/sunng87/cargo-release
…On Fri, Jul 31, 2020 at 11:06 AM Max Countryman ***@***.***> wrote:
As for the documentation, the process to update the version number on
master is not documented (I think Andy uses some tool for that?), including
a reminder to follow semver, as described in CHANGELOG.md.
Thanks for pointing that out. @andygrove <https://github.com/andygrove>
would you mind sharing the process/tool we should use for that? I can
update the release doc accordingly.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#238 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHEBRFV2PXPK7QXTODLYLTR6L2YVANCNFSM4PHP7BWQ>
.
|
|
||
## Process | ||
|
||
Please ensure you follow the correct format when creating new tags. For | ||
instance: | ||
Using `cargo-release` we can author a new minor release like so: |
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 not thinking of the new releases as "minor", so perhaps it would be useful to remind that this means 0.(N+1)
in our context?
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 that makes sense to me. Maybe we should simply link to the CHANGELOG where that's described?
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 CHANGELOG doesn't mention "minor" releases either. Technically, "minor" is the correct term with regards to semver, but in context of sqlparser using it without mentioning semver is slightly weird. Do what you think is best, I don't have a strong opinion on if or how this should be addressed.
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'll leave this as-is for now.
Anything that remains on this one? Would like to see this in action! |
I was wondering about that as well! A couple of ideas for the future:
|
|
Sorry, I haven't had a chance to get back to this. I'll take another look this evening--those all sound like good ideas but perhaps we can circle back and prioritize getting this live first? |
Sure, this is exactly what I meant by calling my notes "ideas for the future"! |
All right, this is merged. Hopefully I configured it correctly. 🤞 |
Great! I pushed a PR updating the changelog (#261) so that we can test out the new release procedure. I also unresolved my comments above, so that they would be visible by default, if you don't mind. |
Continuing from #238 (comment)
it seems you didn't implement this? I'll note that the newer tags start with [edit] also note that future changes are being discussed in #263 |
I'm not sure I follow? I implemented what Andy had suggested, which I believe was to use cargo release. So the naming is handled by cargo release now. |
Andy didn't say anything about the naming of tags. Older cargo-release used to create X.Y tags and the current version creates vX.Y tags, which explains the inconsistency you found. You initially intended to standardize on using tags named "X.Y" and even put |
This introduces a new section of the GitHub Actions workflow which will
publish the crate upon a new tag being pushed. Note that this requires a
new project secret,
CRATES_TOKEN
.