Skip to main content
Parse, lower, validate. No model, no database, no network, no account. It’s free, and it’s meant to be run constantly.

​
Three outcomes, not two

​
error
The app doesn’t hold together: a reference points at nothing, a lifecycle names a state that doesn’t exist, a screen is bound to a field that was removed. Fix it.
​
not an error
It holds together but isn’t a finished application yet. No screen to land on, nothing to create. This is the normal state mid-build, and treating it as a failure would make “look at it running” the one thing you can’t do while building.
​
done
It holds together and it’s a whole application.
Only the first is a failure. A CI job that fails on the second will fail on every honest work in progress, which teaches everyone to ignore it.

​
Asking about a target

A separate question from validity. This asks whether that specific generator can build this app, and lists anything it can’t. See Targets.

​
In CI

The whole check runs offline from a clone, with no services and no secrets.
That second step is worth having. cordango fmt is deterministic, so a non-empty diff after running it means someone hand-edited and didn’t format, and every diff in that file after theirs will be noisier than it needs to be.

​
Checking the workspace rather than the apps

Problems that aren’t source errors: an app registered in cordango.yaml whose directory is gone, a credential pointing at an instance that no longer exists. check is about an app. doctor is about the workspace around it.

​
Before publishing

cordango publish runs the same pipeline itself, and it won’t send a workspace that doesn’t hold together. It also checks every selected app before sending any of them, because publishing three apps and failing on the fourth would leave an instance holding half a workspace whose cross-app references no longer resolve. So you don’t have to check first. Do it anyway. A failure at your terminal is cheaper than one halfway through a deploy.