libsdl-org / setup-sdl

GitHub action for providing SDL.
The Unlicense
27 stars 3 forks source link

Error on Ubuntu; server closes with 500 on downloading SDL2 tarball. Only present on Linux. #23

Open ProjectHSI opened 10 months ago

ProjectHSI commented 10 months ago

Error on downloading and extracting the SDL2 tarball, of which is only present on Ubuntu.

 /home/runner/work/_actions/libsdl-org/setup-sdl/main/packed/index.js:46431
    throw new import_request_error.RequestError(message, 500, {
          ^

RequestError [HttpError]: other side closed
    at /home/runner/work/_actions/libsdl-org/setup-sdl/main/packed/index.js:46431:11 {
  status: 500,
  request: {
    method: 'GET',
    url: 'https://api.github.com/repos/libsdl-org/SDL/zipball/15ead9a40d09a1eb9972215cceac2bf29c9b77f6',
    headers: {
      accept: 'application/vnd.github.v3+json',
      'user-agent': 'octokit-rest.js/20.0.2 octokit-core.js/5.0.2 Node.js/20.8.1 (linux; x64)',
      authorization: 'token [REDACTED]'
    },
    request: { hook: [Function: bound bound register] }
  }
}
madebr commented 10 months ago

Have you recently run a lot of (parallel) builds? I've also seen this error and think this is caused by using up all GitHub tokens. I opened https://github.com/libsdl-org/setup-sdl/issues/22 to think about caching the SDL sources, and/or fetch the sources in a different way.

ProjectHSI commented 10 months ago

Have you recently run a lot of (parallel) builds? I've also seen this error and think this is caused by using up all GitHub tokens. I opened #22 to think about caching the SDL sources, and/or fetch the sources in a different way.

This is correct. I run 4 builds in parallel. 2 for Linux (gcc & clang), 1 for Windows (cl/msvc), and 1 for MacOS (gcc). The latter two both succeed (at this step).

It could be possible that the github tokens dried out but that wouldn't explain the big picture as Windows and MacOS builds both succeed (they failed due to #24 however, might be that was my fault).

KenVanHoeylandt commented 10 months ago

I have the same issue: https://github.com/ByteWelder/Tactility/actions/runs/7596080088/job/20689375551?pr=16 This is my first CI job with the SDL dependency.

ProjectHSI commented 10 months ago

I have the same issue: https://github.com/ByteWelder/Tactility/actions/runs/7596080088/job/20689375551?pr=16 This is my first CI job with the SDL dependency.

HI there. I'll have a look at finding a workaround for Linux. I think you have to clone the version of SDL you want to a directory, tell the CMake script to use Vendored SDL via a variable set by the CI script. As far as I know installing SDL the normal way via a Vendored SDL won't work on MacOS (it just freezes for some reason).

madebr commented 10 months ago

Does this still happen? Before implementing a different way to fetch the SDL sources, I'd like to try reverting the nodejs version from 20 to 16. You can test this by switching to the try-node16 branch.

KenVanHoeylandt commented 10 months ago

The original issue seems to be solved, as the action's data is fetched from cache:

Looking up a SDL_image build in the cache setup-sdl SDL_image state = e93427b44940a3a7ca50cf2ffb7fdd49fa615dee40b0e8f9e7ea19f0694859f3 Cache Size: ~0 MB (261901 B) /usr/bin/tar -xf /home/runner/work/_temp/3c36ccc5-403b-463b-a9d8-c0c99bbbdfd1/cache.tzst -P -C /home/runner/work/Tactility/Tactility --use-compress-program unzstd Cache restored successfully SDL_image found in the cache: key = setup-sdl-SDL_image-e93427b44940a3a7ca50cf2ffb7fdd49fa615dee40b0e8f9e7ea19f0694859f3 SDL_image version is 2.8.2 Received 261901 of 261901 (100.0%), 0.2 MBs/sec

I cannot yet conclude whether it is completely fixed because my build now fails with a different reason:

[ 80%] Linking C executable app-sim /usr/bin/ld: cannot find -lSDL2: No such file or directory

This is possibly an issue in my project, so I need to investigate it. Context: https://github.com/ByteWelder/Tactility/actions/runs/7603080544/job/20704376936?pr=16

madebr commented 10 months ago

@KenVanHoeylandt The SDL configuration files generate targets in the SDLxxxx namespace. This patch fixes that:

--- a/app-sim/CMakeLists.txt
+++ b/app-sim/CMakeLists.txt
@@ -7,7 +7,7 @@ target_link_libraries(app-sim
     PRIVATE tactility-core
     PRIVATE lvgl
     PRIVATE lv_drivers
-    PRIVATE SDL2
+    PRIVATE SDL2::SDL2
 )

 target_link_libraries(app-sim ${SDL2_LIBRARY})

Likewise, for SDL2_image, link to SDL2_image::SDL2_image.

ProjectHSI commented 10 months ago

Hey sorry I didn't get your messages, I hope you're still online. I'll investigate the potential fixes.

ProjectHSI commented 10 months ago

On the Node 20 branch, this still happens. Investigating the Node 16 branch.

ProjectHSI commented 10 months ago

By changing the branch using

- uses: libsdl-org/setup-sdl@try-node16

it doesn't work but with a different message.

Screenshot 2024-01-22 070104
KenVanHoeylandt commented 10 months ago

@madebr Thanks, that solved it! I ended up using the proper variable: ${SDL2_LIBRARIES}

The build then succeeded, but the original problem was back in the build afterwards: https://github.com/ByteWelder/Tactility/actions/runs/7603931718/job/20706241039

Conclusion: it fails intermittently depending on whether it uses the cached data or not.

ProjectHSI commented 10 months ago

@madebr I'm sorry if you're busy working on SDL2 or this project but this issue isn't fixed yet - Nothing has changed on the master branch.

thangisme commented 9 months ago

I'm also encountering this issue, is there any update yet?

ProjectHSI commented 9 months ago

I'll have a look at finding a workaround for Linux. I think you have to clone the version of SDL you want to a directory, tell the CMake script to use Vendored SDL via a variable set by the CI script. As far as I know installing SDL the normal way via a Vendored SDL won't work on MacOS (it just freezes for some reason).

Try doing this.