Closed mrcjkb closed 6 months ago
@swarn One thing I forgot to mention: The way I've implemented this workflow, it only triggers if you push a tag, but not if you create a tag via GitHub Releases.
There's a more complicated setup that solves this problem, which we provide a tutorial for.
But I think for your case, this simple approach should suffice :smile:.
I agree!
Running into a little bug here, I think. I added the release tag, the ran the workflow manually. It uploaded a fzy-lua
rock, rather than a fzy
rock.
Ha, I added a name
field, but now it uploads a main-1
rock to luarocks rather than a 1.0.1-1
rock. I'll stop messing with it until you get a change to check it out.
Oh yeah, I missed that :sweat_smile: I see you've already added the name.
Ha, I added a
name
field, but now it uploads amain-1
rock to luarocks rather than a1.0.1-1
rock. I'll stop messing with it until you get a change to check it out.
This is probably because you triggered it on the main
branch.
If you trigger it on the tag, it should work (but it might use the old workflow file, so it might be best to delete the tag and create a new one).
fzy 1.0.2 is live on luarocks and your windows builds should all succeed now. Thanks for the help!
Yay :rocket:
It's still failing on the windows GitHub runner I'm using, with
fzy_native.obj : error LNK2019: unresolved external symbol has_match referenced in function filter
fzy_native.obj : error LNK2019: unresolved external symbol match referenced in function score
fzy_native.obj : error LNK2019: unresolved external symbol match_positions referenced in function filter
C:\Users\RUNNER~1\AppData\Local\Temp\luarocks_build-fzy-1.0.2-1-4475950\fzy_native.dll : fatal error LNK1120: 3 unresolved externals
:thinking: I wonder if that's a 32 bit vs 64 bit issue, since I'm using windows-2019
,
or maybe it's missing some build dependencies.
Oh, I know what it is. The luarocks-tag-release action needs a rockspec template in your case. I will add this in another PR
Closes #11