Given recent events, actions should better be pinned to SHAs now, not tags.

And #3994 will need to be fixed until April as well.

There were 1 errors:
 - /home/runner/work/awesome/awesome/tests/test-awful-layout.lua: 2025-03-29 02:32:38 E: awesome: Error during a protected call: lib/awful/layout/init.lua:267: bad argument #-2 to 'geometry' (value in [-32768.0, 32767.0] expected, got 65576.0)

Well, this one is going to be funny...

Since we have some activity today, I figured I should provide an update here. I have a slow-work-in-progress branch on my fork at #4024.

• I have an (uncomited) Devcontainer config that reproduce the same conditions we have in the CI environment, so it eases the debug work
• I have tracked down with the help of GitHub Copilot the overflow error to some maths in the tile layout (1f587b6). I'm not completely satisfied with this fix, but it's the less intrusive I could think of.
• The apidoc generation in the CI has many changes I still need to review (because it seems not normal to me that generated images has changes)
• The LuaJIT tests fail consistently, I think because of some collectgarbage (?) (At least, that's a common line in every test that randomly fails)
• EDIT: codecov seems broken, I need to understand what happen

i wonder whatever skipping those 2 (or their number is fluctuating?) problematic tests for luajit setup specifically be a reasonable way to unlock CI in order to start merging quite a a big accumulated queue of PRs?

and thanks a lot for all the debugging done on this 🔥🔥🔥

• The LuaJIT tests fail consistently, I think because of some collectgarbage (?) (At least, that's a common line in every test that randomly fails)

Looks like "despite" would be the more accurate wording here.
The common case in text-naughty-screen and test-screen-changes is to drop a reference and then wait for it to be removed completely. The collectgarbage calls are there to speed things up by forcing the GC to run now, rather than having to rely on it to "eventually" clean up the references. Removing calls to collectgarbage will only make it worse, as it's then even less deterministic if/when the object gets cleaned up.

The fact that these tests fail suggests that somewhere, there is still a strong reference that prevents the GC from actually removing the underlying object.

Sooooo it took me some additional researching and try-and-fails, but it actually seems like there was an issue with the memory management from LuaJIT with lightuserdata. Using an updated version of LuaJIT makes the error vanish.

Also, updating the Actions for CodeCov unblocked it! I'm making big progress 🚀

Codecov Report

❌ Patch coverage is 0% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 54.51%. Comparing base (691e364) to head (de0d2ec).
⚠️ Report is 2 commits behind head on master.

@@            Coverage Diff             @@
##           master    #3999      +/-   ##
==========================================
+ Coverage   48.37%   54.51%   +6.13%     
==========================================
  Files         194      263      +69     
  Lines       22400    31257    +8857     
  Branches        0     1149    +1149     
==========================================
+ Hits        10837    17040    +6203     
- Misses      11563    13706    +2143     
- Partials        0      511     +511     

Hello, I've rebased/pushed the working commits from my private branch to here. The CI is working again!

Things that should be noted :

• As mentioned earlier here, and described in the commit message for 73f551a: This is just a mitigation patch to allow the test to pass. I couldn't figure out the root cause for this error.
• The Update API docs workflow is green, but the script actually fails. The error is that the secret token used is only available in the main repository. When submitting a PR, the workflow run as from your fork, hence don't have access to the token. I was induced in error thinking something was wrong because lasts PRs from Elv had some comments from the "awesome bot". This is because they were branches from this repo and not his fork. So ultimately, we'll see if the script works only after merge, with the workflow triggered from master.
• I used the luarocks/gh-actions-lua to install LuaJIT from source in the CI. LuaJIT uses rolling release, so it sounds best suited to always (and only) test against the git-master version. If really needed, we can add (with new PRs) entries in the workflow matrix to test against legacies versions. In the long term, I think it would be benefited for us to use this Actions to install all Lua versions (and also to use the other Actions to install Luarocks).
• There is a new "Correct Lua variables paths" step in the main workflow, it is needed to use the github.workspace variable. I corrected both LUAINCLUDE and LUALIBRARY, but only the fix for LUAINCLUDE is strictly necessary. The path fix is needed to build Luarocks. I have kept the --with-lua-include flag, but I'm pretty sure we actually don't need it anymore with the gh-actions-lua.
• We may have issue with how CodeCov calculate the coverage. It was unnoticed with Move the C coverage to the CodeCov GitHub Action #3947 that says - Coverage master:91.26% diff:48.52% +/-:-42.74%. So we have somehow lost about half of the coverage.
• With the very last debug session, I had a new error with integration tests with Lua5.2 /home/runner/work/awesome/awesome/tests/test-awful-client.lua: Error: timeout waiting for signal in step 11/138 (@20) (.../runner/work/awesome/awesome/tests/test-awful-client.lua:221). If it doesn't happen here, I'll skip debugging it now.

Thank you for the merge @actionless 🚀

considering that @Elv13 previously approved the prev version of the PR i think there is no need to futher block the CI, so finally we could merge some of long-waiting PRs

thanks again for your great pipeline investigation, @Aire-One 🚀