CI: fix the build for LuaJIT and OpenResty on Windows

[luau-project]

Description

Fixed the CI build of luasocket for LuaJIT and OpenResty on Windows. Now, CI is working correctly on all scenarios.

Changes

1. Currently, most MinGW-w64 providers (like the one used by GitHub) ship a C compiler targeting the Universal C Run Time (UCRT). However, the current LuaRocks version (3.11.1) used by most GitHub Actions incorrectly detects the MSVCRT of LuaJIT and OpenResty on Windows. Thus, MSVCRT was set explicitly to UCRTBASE;

Note

This LuaRocks issue was already fixed by luarocks/luarocks@99c7267. However, it was merged after LuaRocks 3.11.1 release.

2. LuaRocks is unable to detect the library directory of OpenResty on Windows. Thus, LUA_LIBDIR was set explicitly to the binary directory of Lua for OpenResty on Windows.

[alerque]

Shouldn't these values be upstreamed into the GH Actions being used here? (Either @leafo's original or the pseudo-official forks in @luarocks, I'm not sure which one will stay as the canonical upstream.) I appreciate the fix and we could stuff it into this project if need be, but it seems to make more sense to just have it fixed in the action.

[luau-project]

Shouldn't these values be upstreamed into the GH Actions being used here?

I'll try to fix it upstream.

Note

Since the upstream merge can take months to happen, I think that incorporating these changes now would benefit everyone submitting PRs to luasocket to get their code well tested on each platform / interpreter. Then, once I get a definitive response upstream, I get back here to downstream the results.

[alerque]

You might get a faster response upstream than you expect. In any event one way we can fix it here for this project is using your PR branch as the action source for these runs, then switching back to the main repo when it has a release that includes the PR.

[luau-project]

You might get a faster response upstream than you expect. In any event one way we can fix it here for this project is using your PR branch as the action source for these runs, then switching back to the main repo when it has a release that includes the PR.

Oh, this seems an interesting solution. I'm investigating this MSVCRT a little deeper before to propose a solution to the maintainers of GH Actions for LuaRocks.

[luau-project]

Update

I opened a PR upstream on luarocks's repo luarocks/gh-actions-luarocks#5, but I didn't receive any response yet.

Changes:

1. Following your suggestion CI: fix the build for LuaJIT and OpenResty on Windows #453 (comment), I changed the LuaRocks action to use the one from my PR branch;
2. During my tests, I found that there is no issue with OpenResty interpreter. The problem with OpenResty lies in the cached version on Windows. The cached version is too old and has some issue, but cleaning the cache (buildCache: false) solves the problem.

Note

Once the cache is updated with a new version, theoretically, restoring it shouldn't be a problem.

Deploy is failing

The deploy job is failing, but it is expected. I reported it upstream lunarmodules/.github#9