setup-sdl icon indicating copy to clipboard operation
setup-sdl copied to clipboard

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

Open ProjectHSI opened this issue 1 year ago • 14 comments

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] }
  }
}

ProjectHSI avatar Jan 16 '24 23:01 ProjectHSI

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.

madebr avatar Jan 17 '24 00:01 madebr

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).

ProjectHSI avatar Jan 17 '24 01:01 ProjectHSI

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.

KenVanHoeylandt avatar Jan 20 '24 18:01 KenVanHoeylandt

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).

ProjectHSI avatar Jan 21 '24 04:01 ProjectHSI

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.

madebr avatar Jan 21 '24 18:01 madebr

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

KenVanHoeylandt avatar Jan 21 '24 20:01 KenVanHoeylandt

@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.

madebr avatar Jan 21 '24 20:01 madebr

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

ProjectHSI avatar Jan 21 '24 20:01 ProjectHSI

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

ProjectHSI avatar Jan 21 '24 20:01 ProjectHSI

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

ProjectHSI avatar Jan 21 '24 21:01 ProjectHSI

@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.

KenVanHoeylandt avatar Jan 21 '24 21:01 KenVanHoeylandt

@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.

ProjectHSI avatar Jan 28 '24 02:01 ProjectHSI

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

thangisme avatar Feb 14 '24 10:02 thangisme

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.

ProjectHSI avatar Feb 14 '24 10:02 ProjectHSI