Debugging configuration

gigadrive debug config resolves your project configuration through the same code path Deploy uses, then prints the result. Run it when a build does something you did not ask for, before you spend time guessing which layer asked for it.

It takes no arguments and no flags.

gigadrive debug config

Config file found at: /home/ada/checkout/gigadrive.yaml

Everything after that first line is the normalized configuration, as pretty-printed JSON.

Where the answer comes from

Gigadrive Network builds the configuration from two independent sources: a config file in the working directory, and framework auto-detection run against the same directory.

The first of these filenames wins, checked in order:

This is the command that tells you which one answered. A project that gains a gigadrive.ts beside an existing gigadrive.yaml switches to the TypeScript file with no notice, and the printed path is the evidence. TypeScript configuration covers what the six module formats expect.

With both a file and a detected framework, the framework defaults are merged first and your file is layered on top, then the merged result is validated as a whole. With only one of the two, that one is used. With neither, the command reports No config file found and no framework detected. and a real deploy would stop there too.

Config file found at: null is the honest answer when everything came from auto-detection, and it is the line to check first if you expect a file to be picked up. A file that is present but sits under a name not in the configuration-file table is invisible to the resolver.

Reading the output

The JSON is the normalized shape the deployment consumes, not a copy of your YAML. Four keys carry most of the answers:

• commands, the shell commands the build runs
• entrypoints, the code that becomes a Function
• routes, how incoming paths map onto entrypoints and assets
• assets, what is published to the edge instead of invoking a Function

A populated warnings array is printed by a deploy as well. errors is always empty in this output, because a config that fails validation never gets as far as the JSON: the messages go to stderr instead, one per line. Configuration documents each field.