AppVeyor CI job broken

[vszakats]

curl-for-win official releases have been traditionally built on AppVeyor CI:
https://ci.appveyor.com/project/curlorg/curl-for-win/history

I thank AppVeyor CI for making these builds possible for such a long time.

Sadly the build no longer worked when I pushed the latest release 8.15.0_5:
https://ci.appveyor.com/project/curlorg/curl-for-win/builds/52560722

It seems the docker installation on Ubuntu 22.04 (latest image) has its
docker repo keys expired, and failing to download docker images. But I'm
not sure. Possibly related to this warning seen earlier:
https://ci.appveyor.com/project/curlorg/curl-for-win/builds/52463568?fullLog=true#L18

There is a PR that aims to update the runner, but it's hard to say when
it will be deployed and if it fixes this issue:
appveyor/build-images#171

The main reason for using AppVeyor CI is that it works smoothly and
reliably, and does not require an account to view and download build logs:
https://ci.appveyor.com/project/curlorg/curl-for-win/builds/52463568

It also retains these logs for a long time, allowing to inspect them for
past releases.

I tried its macOS runner, but wine gets stuck, and with wine disabled,
it hangs at random points in cmake configure stages. I don't know the
reason:
3250ad7

The Windows runner would be an alternative, but I'm not using Windows
locally. I do also prefer an open source stack for these builds to offer
reproducibility for everyone. Also the script needs a bash/POSIX shell
and unixy tools, and haven't tested it on MSYS2 for a long time.
Windows-hosted builds also perform poorly in most cases we've seen.

Possible alternatives:

• stay on AppVeyor CI and
  • report this issue
  • wait till the AppVeyor CI team resolves it
  • downsides:
    • AppVeyor CI seems stagnant recently
    • needs docker. no podman support.
  • upside:
    • continuity
• move these build to GitHub Actions
  • downsides:
    • requires accessing GitHub
    • requires a GitHub account to see build logs
    • build logs are deleted after a short time period (90 days maximum)
      With cosign-ed binaries the lack of logs may be less of a problem,
      but I still find an issue with less transparency. It also makes debugging
      difficult if anything comes up.
  • upsides:
    • it works
      tested here:
      28641f1
      https://github.com/curl/curl-for-win/actions/runs/16988867720
    • daily builds are already on GHA
    • performance
    • simplifies the CI stack
• move to GHA than move back to AppVeyor CI when it works again
  • downsides:
    • annoying to follow
    • annoying to do
• move to the Woodpecker CI on codeberg.org
  • downsides:
    • need to mirror/push the curl-for-win repo to codeberg.org
    • CI access needs to be requested
      https://codeberg.org/Codeberg-e.V./requests/issues
    • CI needs to be learned and setup from scratch
      https://codeberg.org/Codeberg-CI/woodpecker
      https://woodpecker-ci.org/docs/intro
    • log access and retention options unknown
    • options, performance and reliability unknown
    • consuming community resources for building for a propriatery OS
  • upside:
    • community-supported, open platform, open tools

[vszakats]

Ah, resolved by removing DOCKER_CONTENT_TRUST=1.
I guess very few uses this security feature, and thus prone to breakage, or
experiation in this case.