search

aerospike / aerospike-server.docker

Dockerfiles for Aerospike Server
Other
141 stars 68 forks source link

Fix curl silently failing with a non 5xx status code is returned by the server #63

Closed LaurentGoderre closed 2 months ago

LaurentGoderre commented 2 months ago

For example:

if pkg_link is: 

-https://artifacts.aerospike.com/.../aerospike-server-federal_7.1.0.0_tools-11.0.0_ubuntu22.04_x86_64.tgz
+https://artifacts.aerospike.com/.../aerospike-server-federal_7.1.0.0_tools-11.0.0_ubuntu22.04_x86_65.tgz

The server returns an HTTP 300 Multiple Choice.

This is causing issues in the new DOI build because there is an error and we can't figure out what it is

https://github.com/docker-library/meta/actions/runs/9319226426/job/25653282798

tianon commented 2 months ago

300 seems like a pretty bizarre status code for a tgz download -- any idea why the server would be returning that? (IMO it'd be much more reasonable to fix that than to work around it here)

LaurentGoderre commented 2 months ago

The 300 is a bit of a red herring. The point is our build is failing because it thinks it got an archive but instead it got an error page ans we have no idea what the error is or why (though it might be because it's pulling from GHA instead of our own builder)

tianon commented 2 months ago

Right, but curl only treats 400+ as an error (which is why -f/--fail didn't catch this), so fixing the server that's returning 300 in the first place feels better than working around this via curl hacks :see_no_evil:

LaurentGoderre commented 2 months ago

Build finally passed. Might have been a transient error.

kportertx commented 2 months ago

Though in this place, I think the script is expecting 200 only. Personally, I prefer when things fail as soon as possible (easier to debug), so I like the idea of amending the template scripts to check for 200. @tianon, thoughts?

kportertx commented 2 months ago

Also @LaurentGoderre, where did this come from:

+https://artifacts.aerospike.com/.../aerospike-server-federal_7.1.0.0_tools-11.0.0_ubuntu22.04_x86_65.tgz

Want to understand how the 5 showed up in x86_65 - should have been a 4.

Never mind, just realized that was a hypothetical situation.