fix: update libcurl in docs pipeline

[jolheiser]

Our docs pipeline has been failing recently, and running the image locally without -s shows

Adding curl-dev appears to fix the issue.

---

Per @silverwind instead we can just update libcurl to make them match.

[silverwind]

Why?

[jolheiser]

Why?

Otherwise curl -L fails with unknown option was passed to libcurl

Our docs pipeline started to fail recently when plugins/hugo published a new version.

If there is a better way, I am open to it.

EDIT: I updated my PR description for clarification, as discussion happened in Discord.

[silverwind]

Huh, looks like curl is seriously broken inside that container. Must be some global config or something, not sure. Do you know where the source Dockerfile for this image lives?

$ docker run -it --entrypoint /bin/sh plugins/hugo
/ # apk add --no-cache curl > /dev/null
/ # curl https://gohugo.io/
curl: (48) An unknown option was passed in to libcurl

[jolheiser]

It comes from https://github.com/drone-plugins/drone-hugo/blob/master/docker/Dockerfile.linux.arm64

Of note, the image it uses as a base, plugins/base:linux-arm64 seems to work fine, so something in the drone-hugo docker seems to be affecting it.

[silverwind]

Issue is curl and libcurl do not match inside the image. Cause unknown, that Dockerfile does not deal with curl. Some layer before might have installed the old libcurl version.

/ # curl -V
curl 7.87.0 (x86_64-alpine-linux-musl) libcurl/7.86.0 OpenSSL/3.0.7 zlib/1.2.13 brotli/1.0.9 nghttp2/1.51.0
Release-Date: 2022-12-21
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM NTLM_WB SSL threadsafe TLS-SRP UnixSockets
WARNING: curl and libcurl versions do not match. Functionality may be affected.

[silverwind]

Opened drone-plugins/drone-hugo#36 to track upstream.

[jolheiser]

🎺 🤖

[silverwind]

BTW we should probably just run hugo in a regular go image using the same syntax we use for other go tools. That way we don't need to rely on obscure images like that one.

go run github.com/gohugoio/hugo@v0.108.0 --help

[silverwind]

#22206 for that.