Inspecting a deployment

Every deployment in Gigadrive Network has a page in the console with four tabs. Which tab you want depends on the question: what is it serving, why did it fail, what did it create, or what is actually in it.

The header

The deployment header shows the current status, the environment the deployment ran in, its branch, the first seven characters of its commit SHA, a button that copies the primary URL, and Visit. A deployment with no branch and no commit shows its own id instead.

More actions holds the two things you can do to a deployment. Redeploy appears once it is Ready or Failed. Cancel Deployment appears while it is still running and stops the build immediately. A deployment that is neither shows "No actions available".

Overview

The Domains card lists every public endpoint assigned to this deployment: its permanent per-deployment URL, its branch URL, and, for a production deployment, the production URL. The one visitors currently reach is marked Current, and any that no longer routes here is marked Inactive. Each row copies and opens.

The Deployment details card covers timing, ownership, and identity. Created is shown in your local time. Queued is the wait before the build started. Build time covers the rest. Initiated by names whoever started it, which is the signed-in user for a manual deployment and the commit author for a push. The deployment id is there to copy into a support request.

A deployment sitting at Waiting for capacity gets a banner instead, naming the memory it asked for, how long it has been waiting, and a short reason. The build has already finished by the time this appears, and the deployment picks up again on its own once capacity is free, so nothing is lost by waiting.

Logs

One stream, containing both the build output and the platform's own step lines. The indicator reads Connecting, then Live, and switches to Reconnecting if the connection drops; nothing is lost, because the stream resumes from where it stopped.

Lines carry a level of INFO, WARN, ERROR, or DEBUG. Search filters what is on screen, Load older logs pages backwards through a long build, and the download button writes the lines currently loaded to a text file. Load the older ones first if you want all of them.

Two empty states mean different things. "Build output will appear here as the deployment runs" means the build has not printed anything yet. "This deployment produced no logs" on a finished deployment means it never got far enough to print, which usually points at the deployment being cancelled or refused before the build started.

For the log of your application answering real requests, which is a different stream, see Runtime logs.

Resources

What provisioning created. The Functions table lists each Function in the deployment with the path it answers, its runtime, and its timeout. Check it when a framework may have collapsed your app into one Function you did not intend, or when a route you expected is missing.

The Resources tab also lists the scheduled triggers this deployment registered and the hostnames pointing at it. An empty tab means provisioning has not run yet.

Source

A browsable tree of the static files the deployment contains, with a search box, expand and collapse, and a file count per directory. This is the tab that settles "did my build actually emit that file", which is worth checking first when a page 404s and the Function looks healthy.

The screenshot

An environment's overview page shows a screenshot of what its active deployment serves, framed like a browser window. Production deployments are captured automatically once they publish. Deployments in other environments are captured when you open the environment page and none exists yet, so the first view of a preview shows "Capturing preview" for a moment.

The screenshot an environment currently shows is kept for as long as that deployment is the newest one. Screenshots of deployments something newer has replaced are deleted after 30 days.

A capture that could not be taken shows "Preview unavailable" rather than an error. The recorded reasons are a site answering 4xx or 5xx, a redirect off the deployment's own hostname, an unreachable host, and a capture that ran out of time.

Outside the console

import { GigadriveClient } from '@gigadrive/sdk';

const client = new GigadriveClient();
const deploymentId = '0197b2f1-2f4a-7a0b-8a2d-333333333333';

const deployment = await client.deployments.get(deploymentId);
console.log(`${deployment.status} since ${deployment.updatedAt}`);

const { items: hostnames } = await client.deployments.getHostnames(deploymentId);
for (const hostname of hostnames) {
  console.log(`https://${hostname.hostname} (${hostname.type})`);
}

const logs = await client.deployments.getLogs(deploymentId, { limit: 100 });
for (const line of logs.items) {
  console.log(`[${line.type}] ${line.message}`);
}

The CLI's --status filter accepts every status except WAITING_FOR_CAPACITY. Ask the API directly for those.