ci: Repeated downloads of shared test assets cause intermittent job failures #36814

Is there an existing issue for this?

• I have searched the existing issues

Current behaviour

GitHub Actions jobs independently download script_assets_test.json from bitcoin-core/qa-assets, even though they use the same test input.

In workflow run 42581720178, three jobs failed during asset preparation with HTTP 504 after exhausting their retries:

• No wallet
• Windows native, clang-cl
• Windows, test cross-built

Alpine encountered the same errors, eventually downloaded the file without authentication, and passed script_assets_tests. A subsequent local download and test also succeeded.

Download locations

The direct GitHub downloads in the CI scripts are:

Dependency sources also reach GitHub through the platform-specific curl definitions in depends/builders and fetch_file_inner. That mechanism already has retries, checksum verification, and a fallback mirror. The lint tools and dependency sources have a different lifecycle from shared test inputs.

Expected behaviour

Acquire shared test inputs once per workflow and distribute the validated files to every consuming job:

1. Add a preparation job that downloads script_assets_test.json with retries, validates its expected content and checksum, and records its source revision.
2. Publish it using actions/upload-artifact.
3. Make every consuming job depend on preparation and use actions/download-artifact, placing the file where the shell and Windows test runners expect it.
4. Have those CI consumers use the prepared file without independently downloading it again.
5. Apply the same pattern to other shared test inputs where appropriate. In particular, fuzz jobs currently acquire qa-assets through separate clones in the shell and Windows paths.

The workflow already uses this artifact handoff for Windows executables. GitHub documents sharing artifacts between dependent jobs.

This would reduce repeated external requests and give consumers identical inputs. Initial acquisition could still fail, but failures would be concentrated in preparation.

Steps to reproduce

The failure is intermittent: run the CI workflow with unit-test consumers enabled. The linked run demonstrates different outcomes when jobs independently request the same asset.

Relevant log output

Shell CI:

curl: (22) The requested URL returned error: 504

Windows CI:

Download failed: HTTP Error 504: Gateway Time-out
Retrying download after failure ...
HTTP Error 504: Gateway Time-out

Environment

• Version: commit ed9a469e3e48e8ae47ee3ce8e982b982b9f35537
• Obtained: compiled from source
• Operating systems: Ubuntu 24.04 and Windows Server 2022/2025
• Execution environment: GitHub Actions CI

How did you obtain Bitcoin Core

Compiled from source

What version of Bitcoin Core are you using?

v32.1

Operating system and version

Devuan 6 "Excalibur"

Machine specifications

GitHub Actions CI runners on Linux and Windows, using the standard repository workflow. Local machine specifications are not relevant to this asset-download failure.

If the qa-assets host (GitHub) is too fragile, it would be better to switch the host than to work around GitHub issues with some GitHub caching. See https://github.com/bitcoin/bitcoin/issues/35574

Thanks for the pointer. I'm not convinced that future plans are a reason to not improve the present.

About Github specifically: in my experience, compared to platforms running systems like CVS, SVN, and now Git, it works quite well. Nobody has been perfect, even TravisCI had its outages, the important thing is that they are acknowledged and sooner than later solved.

Also having a "permissionless" CI as it is now, where a contributor can run all CI tests without fuzzing around permissions on a specific platform, just a Github account, is a bit advantage for inclusion and enrollment. Would a specific new platform allow this, or it will have an allow-list for users able to run it?

Last not least, I really love the automations that are now in place on Github's PRs, Ralph's reviews are very useful, I wouldn't want to lose that.

So all things considered I'd be happy to see github action runs being more deterministic for the time being and I'd volunteer for it.

Ciao!

The CI will have to download stuff from the internet one way or another. If GitHub is down, more code in the yaml can't bring it back up.

OK these are two different problems, I'm not trying to solve both:

1. github is down: I cannot solve it, have no idea how.
2. github is up, but its CI fails randomly because of the way github actions download assets from github itself: this can be and should be solved avoiding use of curl, but using an action for asset downloads.

I'd like to solve 2. and its easy.

Hi, Can I start working on this I got how to close this It would be great if you assign me please

2. github is up, but its CI fails randomly because of the way github actions download assets from github itself: this can be and should be solved avoiding use of curl, but using an action for asset downloads.

"504: Gateway Time-out" means that the upstream server is down. Again, it is impossible to remotely start the upstream server again from the yaml. This has nothing to do with curl.