Luarocks tag release

[mrcjkb]

fzf-lua is a common dependency across Neovim plugins (see for example gennaro-tedesco/nvim-possession#19). Using luarocks may alleviate the need for users to specify their plugins' dependencies in their plugin manager (e.g., vim-plug or packer).
See this blog post for more details.

This PR adds a release workflow that publishes this plugin to LuaRocks whenever a tag is pushed, as well as a rockspec that can be used to release to the dev channel or install this plugin from source using the luarocks CLI.

For the release workflow to work, someone with a LuaRocks account will have to add their API key to this repository's secrets.

Note that I have added a shield to the readme that assumes the existence of an ibhagwan/fzf-lua LuaRocks module.

[ibhagwan]

Ty @mrcjkb!

There was already an accepted PR that added a rockspec by @teto, see #521.

As for the workflow I’m not sure how that’s going to work as I don’t plan on cadence releases, tags or semver, I make sure nothing breaks and release main, while I do think such workflows are valuable for certain plugins I don’t see any benefit of changing the way fzf-lua is released, it’s been very stable and aside from the occasional feature request / minor bug there aren’t many new changes.

That said, is there any value in a luarocks publishing workflow given updates are just a git push to the main branch?

[mrcjkb]

Ah, thanks for the info. That makes the rockspec I added redundant :)

To answer your question: The scm rockspec that @teto added would work for publishing fzf-lua to the dev channel of Luarocks. Unfortunately, by default, Luarocks will refuse to install packages that are only on the dev channel.

Neotest has a similar worfflow to you. using the semantic-release plugin to automatically publish a new release whenever a PR is merged into master. Maybe something like that would be useful for you? If so, I'd be glad to look into setting it up.

[ibhagwan]

Neotest has a similar worfflow to you. using the semantic-release plugin to automatically publish a new release whenever a PR is merged into master. Maybe something like that would be useful for you? If so, I'd be glad to look into setting it up.

Ty for this info @mrcjkb, the issue is I’d like to avoid “releases” altogether, the way I view this plug-in is merely a bunch of scripts that call fzf_exec (the main API) which don’t require official releases, I don’t want to over complicate the maintenance by requiring branches and PRs for every change, perhaps I would look at this differently if the plug-in was under heavy development but as it stands we’re talking about a few lines of codes getting pushed once in a while.

[mrcjkb]

I don’t want to over complicate the maintenance by requiring branches and PRs for every change,

The workflow doesn't require PRs or branches. It can be configured to trigger on any push to the main branch.

But if you don't want tags to be generated on every commit, I could look into updating the luarocks-tag-release workflow to support publishing incrementally increasing versions without needing tags.

[ibhagwan]

But if you don't want tags to be generated on every commit

I'd rather not, either I make the tags myself properly or it's just another commit hash with less felxibility if I make a quick rebase fix.

[mrcjkb]

Then I can look into adding support for untagged releases (with incrementing dummy versions for luarocks) to the workflow (if you would be open to that).
To ensure not every rebase fix triggers a build, the triggers could look something like this:

on:
  workflow_dispatch: # allows manual triggering
  schedule:
    - cron: '0 0 * * 0' # runs weekly on Sunday at 00:00

It would be great to have fzf-lua on luarocks for the sake of plugins that depend on it, and for the possibility of using luarocks as a plugin manager.

[ibhagwan]

Then I can look into adding support for untagged releases (with incrementing dummy versions for luarocks) to the workflow (if you would be open to that).

That would be great if we can get luarocks publishing while not changing anything in the current workflow!

[mrcjkb]

Then I can look into adding support for untagged releases (with incrementing dummy versions for luarocks) to the workflow (if you would be open to that).

That would be great if we can get luarocks publishing while not changing anything in the current workflow!

Done 😄
I have tested various scenarios with my fork.

[ibhagwan]

Amazing work, tysm @mrcjkb!

Gonna do some testing on my end and see to it that I understand it all and merge.

[ibhagwan]

Tysm @mrcjkb for this amazing addition!

Now we have to wait for the workflow to do it's thing :-)

[mrcjkb]

Glad to contribute 😄
Thanks for supporting this!

[ibhagwan]

Just realized the merge missed midnight UTC by a few minutes lol

We’ll see what happens tomorrow, I added the LUAROCKS_API_ KEY secret, hopefully should be smooth.

[mrcjkb]

It can also be triggered manually :)

[ibhagwan]

It can also be triggered manually :)

TIL :)

Success!

https://luarocks.org/modules/ibhagwan/fzf-lua

[teto]

that's awesome thnaks ! I will update nixpkgs with all those new tagged releases this week !

[ibhagwan]

Hi @mrcjkb, would you help me find the issue why the workflow failed?

I’ve changed the names to luarocks-release, it successfully ran once since then but failed the next time, pretty sure it’s unrelated to the rename, the failed job:
https://github.com/ibhagwan/fzf-lua/actions/runs/4219023360/jobs/7324003458

[mrcjkb]

Hi @mrcjkb, would you help me find the issue why the workflow failed?

I’ve changed the names to luarocks-release, it successfully ran once since then but failed the next time, pretty sure it’s unrelated to the rename, the failed job: https://github.com/ibhagwan/fzf-lua/actions/runs/4219023360/jobs/7324003458

For some reason, it failed to fetch the license info via the GitHub API. Maybe the request timed out?
You could either try manually triggering it again or explicitly set the license in the workflow:

with:
  license: "AGPL-3.0"

[ibhagwan]

explicitly set the license in the workflow:

which task should have the with clause or should these lines be atop the file?

[mrcjkb]

That would be the upload task

      - name: LuaRocks Upload
        uses: nvim-neorocks/luarocks-tag-release@v2.1.0
        if: ${{ env.NEW_COMMIT_COUNT > 0 }}
        env:
          LUAROCKS_API_KEY: ${{ secrets.LUAROCKS_API_KEY }}
        with:
          version: ${{ env.LUAROCKS_VERSION }} 
          copy_directories: |
            doc
            plugin
          license: "AGPL-3.0"

[ibhagwan]

That would be the upload task

      - name: LuaRocks Upload
        uses: nvim-neorocks/luarocks-tag-release@v2.1.0
        if: ${{ env.NEW_COMMIT_COUNT > 0 }}
        env:
          LUAROCKS_API_KEY: ${{ secrets.LUAROCKS_API_KEY }}
        with:
          version: ${{ env.LUAROCKS_VERSION }} 
          copy_directories: |
            doc
            plugin
          license: "AGPL-3.0"

Worked great, ty @mrcjkb!

https://github.com/ibhagwan/fzf-lua/actions/runs/4225732245/jobs/7338373443