ci: update caddy job to use GitHub Releases

[Ayesh]

The caddyserver.com download page is unreliable, and it also recommends to use GitHub releases instead.
Replaces #13295.

[iluuu1994]

Thanks! It might still make sense to use the timeout values from GH-13295.

[Ayesh]

Added timeouts, thank you!

[TimWolla]

This change is clearly correct, but I wonder if we should use the gh CLI binary to download the release (https://cli.github.com/manual/gh_release_download), because I'm not 100% sure if unauthenticated access to the release API might be rate-limited.

In any case this change should be applied to the earliest branch that has the setup-caddy action.

[TimWolla]

Example: gh release -R caddyserver/caddy download --pattern 'caddy_*_linux_amd64.tar.gz'.

[Ayesh]

Definitely makes more sense to use gh in GH actions. I will update the PR after some tinkering.

[Ayesh]

I tried with gh with the following:

gh release -R caddyserver/caddy download --pattern 'caddy_*_linux_amd64.tar.gz' -O - | sudo tar -xz -C /usr/bin caddy

In GH Actions, I'm seeing this:

gh: To use GitHub CLI in a GitHub Actions workflow, set the GH_TOKEN environment variable. Example:
env:
GH_TOKEN: ${{ github.token }}

I think it'd be more involved to deal with tokens, so I'd say lets go with the direct links for now.

As far as I see from HTTP headers and online, there is no hard limit to those URLs; only api.github.com is rate-limited.

[TimWolla]

I think it'd be more involved to deal with tokens, so I'd say lets go with the direct links for now.

Not really. That github.token is automatically provided by GitHub Actions and valid for a single run only. I thought gh would be able to automatically consume it, but specifying it explicitly is not much more complicated. You should be able to copy that suggested snippet as-is into your workflow file like this:

 - shell: bash
env:
GH_TOKEN: ${{ github.token }}
run: |
set -x
gh release -R caddyserver/caddy download --pattern 'caddy_*_linux_amd64.tar.gz' -O - | sudo tar -xz -C /usr/bin caddy
sudo chmod +x /usr/bin/caddy
sudo caddy start --config ext/curl/tests/Caddyfile

[Ayesh]

Ah perfect! I made a quick test and it worked. Submitting said changes for review. TIL, thank you @TimWolla.

[TimWolla]

Now merged into PHP-8.1+. This is a clear improvement, thank you!

[cmb69]

Hmm, did this ever work? Apparently, it fails all the time: https://github.com/php/php-src/actions/runs/10493648028/job/29068097535#step:8:20

The issue had been reported by @Disservin, and I only now had a look.

According to https://stackoverflow.com/questions/68951888/gh-is-not-recognized-error-while-trying-to-create-github-repo-from-command, we would need to install gh first.

[Ayesh]

It seems to be not working on LINUX_X64_DEBUG_ZTS_ASAN builds, but works on LINUX_X64_RELEASE_NTS builds.

But yeah you are right, lack of gh seems to be the issue, I believe caused by the difference in runs-on images.