-
Notifications
You must be signed in to change notification settings - Fork 434
ci: automated releases and luarocks uploads #1923
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
| - uses: google-github-actions/release-please-action@v4 | ||
| with: | ||
| release-type: simple | ||
| token: ${{ secrets.PAT }} |
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.
This personal access token would need to be added to this repo's secrets.
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.
how about using default token, secrets.GITHUB_TOKEN
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 won't be touching this PR for now, due to inactivity.
See my last 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.
@wsdjeg the reason for not using secrets.GITHUB_TOKEN is that it won't trigger any workflows: https://github.com/googleapis/release-please-action?tab=readme-ov-file#other-actions-on-release-please-prs
The non-default token is required in order for release-please releases to trigger the release workflow that uploads the rockspec to luarocks.org.
|
@hrsh7th no interest in this? The luarocks package and latest tag being so out of date is a bit of a footgun for luarocks/rocks.nvim users. |
and this days also lazy.nvim |
|
Since we haven't received a response, we've removed nvim-cmp 0.0.1 from the luarocks.org root manifest and uploaded a This isn't ideal, because dev rocks can't be pinned to a revision, but at least luarocks/rocks.nvim users can use an up-to-date version of this plugin. If you ever decide to merge this, please let me know, because we will have to relinquish our rock. |
|
since this PR will not be updated, so closed. ref: https://github.com/hrsh7th/nvim-cmp/pull/1923/changes#r2442499195 |
|
yeah, I will try to maintain this project. |
In that case, would you mind reopening this PR for me and marking it as draft? |
ci: bump luarocks-tag-release to v7
|
I've rebased this PR. The test failure seems unrelated. |
|
I can merged this PR, BUT I can not create repo's secrets. |
In that case, perhaps we should remove the luarocks upload workflow from this repo (so that this repo only creates automated release PRs) and then add nvim-cmp to NURR, which checks for new releases every 4 hours. Edit: Done. |
Without a custom personal access token, the workflow can't be triggered by releases created by the release-please workflow. So instead, the luarocks upload will now be handled by [NURR](https://github.com/lumen-oss/nurr), which checks for plugin releases every 4 hours.
|
Yeah, we can use GITHUB_TOKEN to generate changelogs.md. |
Hey 👋
This PR introduces a release-please workflow that automatically opens (or updates) a release PR (which updates a changelog) when a conventional commit is merged into the
mainbranch.Here's an example of what a release PR looks like:
The nice thing about this workflow is that you get to decide when to merge a release PR.
When doing so, the same workflow creates a release tag and publishes a GitHub release, with the (SemVer) version bump determined from the conventional commit messages.
If you add a personal access token to this repo's secrets (I assumed it to be named
PATin this PR), each release will automatically trigger a luarocks upload. I have modified the workflow file to work nicely with this.Important
conventional commit messages. As there has not been a release yet,
it will likely start at version 1.0.0. You can change the initial version with a manifest file.
included in release notes. You could enforce this with a GitHub action. Personally, I haven't ever had a need to do so.