Setup repository tooling

[alerque]

Besides these changes we should probably add some rockspecs, for example at least the last published stable version and a dev version just for consistency...

[Tieske]

yes, agreed.

@teto The common approach is to have a dev rockspec at the toplevel, and released rockspecs in ./rockspecs/. See this repo for an example: https://github.com/lunarmodules/Penlight

[teto]

wyhyat does this do ?

[teto]

link for myself https://github.com/lunarmodules/.github

[alerque]

Any time the rockspec files change and are pushed to the default branch, they are tested against several versions of Lua & LuaRocks to make sure they build properly. If they do, it publishes the rockspec to luarocks.

This particular line is a workflow fragment that figures out what, if any, rockspec files have been modified since the last push.

[teto]

I've already seen that convention, fine by me. I have no experience with github actions so I dont know if this is equivalent but @mrjkb developed an action to push to luarocks https://github.com/nvim-neorocks/luarocks-tag-release on new tags.

[alerque]

This is the first time I've seen that particular action, but @mrcjkb and I should probably compare notes because it looks like there is a lot of overlap. Or system is probably a bit more opinionated since it was developed specifically to match the conventions we use here on @lunarmodules and wasn't built to be totally generic.

[teto]

as i want to update the nix lua package set, the sooner it's merged and we have a fixed rockspec, the happier I am.
I am happy that the 2 github actions now know about eachother but I wouldn't delay the merge over this.

[mrcjkb]

This is the first time I've seen that particular action, but @mrcjkb and I should probably compare notes because it looks like there is a lot of overlap. Or system is probably a bit more opinionated since it was developed specifically to match the conventions we use here on @lunarmodules and wasn't built to be totally generic.

Sure 😃
The luarocks-tag-release workflow was initially aimed at neovim plugin authors who don't (want) to know about rockspec. But it's meant to be compatible with any luarocks package.
Rather than using the common convention of a rockspecs/ directory, the workflow generates a release rockspec from a template and GitHub metadata.

[Tieske]

this looks good to me. Once this is in, the rockspecs can be fixed right?

[alerque]

Yes. Or I can add them here, it doesn't make much difference. Adding them later will produce a CI run failure because it won't be able to republish the existing ones, but that is as intended.

[teto]

@alerque whatever works for you I can add the rockspec then

[alerque]

Go for it.