Auto release version with Hasura
aaronhayes opened this issue · comments
It would be great to have this package auto publish every time Hasura releases a new version. This should be possible using GitHub Actions + CronJobs.
A good starting reference:
https://github.com/peter-evans/create-pull-request/blob/master/docs/examples.md#use-case-create-a-pull-request-to-update-x-periodically
Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.92. Please mark this comment with 👍 or 👎 to give our bot feedback!
Links: app homepage, dashboard and code for this bot.
@aaronhayes Thank you very much for detail suggestion :)
I've considered the auto-publish as well. However, I concluded not to do so.
Once an npm package is published, it can't be edited.
But there's no guarantee from Hasura's release convention.
(Hasura has already changed their convention before (e.g. appearance of hasura-cli@beta tag))
This made me try to be as safe as possible.
Thus I haven't automated publishing.
But I am sure this decision is not fixed, so want to keep the issue open for a while.
Feel free to leave any comments and suggestions.
@jjangga0214 that makes sense, appreciate the thought you've put into that!
Maybe there is a solution somewhere in between? If we used cron jobs to create the PR, we would still have a manual gate.
It looks like, unless something major changes upstream, the PR only needs to bump the package version number, so unless I'm mistaken (@jjangga0214 may correct me here) it only takes a few seconds anyway. See PR #43
it only takes a few seconds anyway.
But not to release. ATM there are 3 (three!) PR for update to 1.3.2. Every one fail for some reason. I think it's not sustainable.
Hasura has already changed their convention before (e.g. appearance of hasura-cli@beta tag)
I think it can be validated with regexp. And how about to add a zero at the end? Like 1.3.2.0 and if something goes wrong, then make a manual release as 1.3.2.1? I've not tested that.
It would be great to have the automatic releases, so that we don't need to fallback to manual installs across team when we need the new features 🙏
It wouldn't just make it more usable, but also more sustainable for @jjangga0214 given how fast Hasura releases new versions, it's not just 2.3.0 #79 and 2.4.1-beta.2 #80 that are missing.
As for the discussed reliability, a regexp check if it's a proper release v(\d+\.\d+\.\d+) or beta v(\d+\.\d+\.\d+-beta\.\d+) version would be sufficient imo.
EDIT: Fixed regexps :)
It seems to me that an automatic PR creation, would be sufficient.
@aaronhayes @zenflow @Bessonov @iki @glassmonkey
Thank you all for the suggestion.
I've taken a conservative attitude because publishing is irreversible.
But my thought has changed. The convention is set to stable. I admit that automation is needed.
As of Today, all publish will be automated(.github/workflows/auto-publish.yml, workflows/auto-publish.mjs).
In fact, v2.32.0-beta.1 is already published automatically.
Thank you!