Full build fails every week because the openapi.tools source URL returns 404

What happens

The weekly Full build workflow has failed on every scheduled run since at least 19 July 2026. The last eight runs all ended in failure, and the data build stops after roughly 97 milliseconds.

The failure comes from the first source in gulpfile.js/metadata.json, which reads from

https://raw.githubusercontent.com/apisyouwonthate/openapi.tools/master/_data/tools.yml

That URL returns 404 today. openapi-tools-processor.js calls axios.get without a catch, so the rejection travels up through gulp and ends the entire run. The log of run 34019950379 shows it happening.

[07:45:02] .../processors/openapi-tools-processor.js https://...
[07:45:02] 'full' errored after 97 ms
[07:45:02] Error in plugin 'gulp-transform'
Message:
    Request failed with status code 404

Why this reaches further than one source

Because the run dies on the first source, none of the later processors execute. That includes tagged-repository-processor.js for the openapi3 and openapi31 topics and open-tooling-repository-issues.js for the issue queue. No tool has therefore been added to src/_data/tools.yaml since the first failing run, and the open tool requests cannot be picked up while this stands.

Why the URL broke

openapi.tools was rebuilt on Astro. The single _data/tools.yml file no longer exists, and every tool now lives in its own Markdown file under src/content/tools/, a directory that currently holds 351 files. The default branch also moved from master to main, so the old path does not resolve under the new branch name either.

The front matter of those files carries the same information the old YAML did, which keeps a fix reasonably small. One entry looks like the block below.

name: Routebase
description: ...
categories:
  - docs
  - testing
link: https://routebase.dev/
oasVersions:
  v2: false
  v3: true
  v3_1: true

Two things that would help

• Catch errors per source, so that one unreachable source degrades that source alone rather than the whole build.
• Point openapi-tools-processor.js at the new layout, reading the directory and mapping the front matter onto the shape the pipeline already expects.

I am glad to open a pull request for either one if that is welcome.

Disclosure

I maintain one of the tools involved. Routebase is listed on openapi.tools and has an open request here as #270, which is how I came across this.

Start with gulpfile.js/metadata.json and openapi-tools-processor.js, then inspect the weekly Full build log for run 34019950379. Trace how the processor reads the old source and how failures propagate through gulp, and compare the expected pipeline shape with front matter under src/content/tools/. Done means the full build no longer stops at this source and later processors can run.