Get App Runtime
GET /apps/{app_id}/runtime
Can this app be built and run yet, and if not, what is missing (M9 J9).
ANSWERS FROM THE CONTROL PLANE, AND SAYS SO. It reports what graph8 has
recorded: a bound source, an assigned hostname, declared secrets, the last
deployment’s state. It does NOT claim the cluster side is ready, because the
namespace provisioner, the image registry and the runtime objects are
separate, unbuilt work. Reporting ready: true on that basis would be the
most expensive kind of wrong: a builder would push and wait for something
nothing can serve.
blockers is the field that matters. An agent driving a build needs to know
WHY it cannot proceed; a bare ready: false sends it guessing, and guessing
against a deploy pipeline is how you get retry loops.
Deliberately cheap: three reads the caller could make themselves across
GET /apps/{id}, /secrets and /deployments. It exists so the answer is
computed in one place, because “am I ready” is a judgement about which
prerequisites matter, and three clients would each get it slightly wrong.
Authorizations
Parameters
Path Parameters
Header Parameters
Responses
200
Successful Response
object
Whether an app is ready to be built and run, and what is missing (J9).
A READINESS REPORT, not a promise. It answers from what the control plane knows: is a source bound, is a hostname assigned, are secrets declared, what did the last deployment do. It does NOT claim the cluster side is ready, because the namespace provisioner, the image registry and the runtime objects are separate work and none of them exist yet.
blockers is the useful field and it is deliberately explicit. An agent
driving a build needs to know WHY it cannot proceed, and a bare
ready: false sends it guessing.
object
Each unmet prerequisite, named. Empty means ready.
True only when nothing in blockers remains. False is the normal answer today.
422
Validation Error