Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.gp.scale.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Overview

This page walks through the Cloud Build and Deploy workflow in the SGP dashboard. The navigation flow is: 
Agents grid → Agent detail → Build detail → Deploy modal → Deployment detail
Prerequisites:
  • An SGP account with access to the Agents tab
  • At least one Agentex agent registered to your account
  • A manifest.yaml and environments.yaml prepared for your agent (see the CI/CD guide for file format details)

​
Viewing your agents

Open the Agents tab from the top navigation bar. This shows all Agentex agents registered to your account.
Agents grid showing registered Agentex agents with status badges and descriptions
Click any agent card to open its detail page.

​
Agent detail and build history

The agent detail page has a metadata header at the top and the build history timeline below.
Agent detail page showing header metadata and build history timeline
The action buttons in the header link to the agent’s live endpoint (Open Agent), its request traces (View Traces), and its performance profiler (View Profiler). Open Agent is only available when the agent has an active deployment. The Build History lists every build for this agent, most recent first. The status badges map to:
StatusMeaning
BuildingImage build is in progress
DeployingBuild succeeded, deployment is actively rolling out
ErrorBuild failed during the image build phase
InactiveBuild succeeded but is not currently deployed
SuccessBuild completed successfully (visible on build detail page)
Click + Add Build to trigger a new cloud build from the UI.
Most teams use CI/CD pipelines for automated builds and reserve the UI button for ad-hoc builds during development.
Click any build row to open its build detail page.

​
Deploying a build

The build detail page shows build metadata, build logs, and all deployments created from this build.
Build detail page showing a successful build with no deployments and a Create deployment button
The Build Logs section is collapsible and includes a search bar for filtering output. Use the build duration in the header to distinguish early failures (missing Dockerfile, bad config) from late failures (dependency errors). To deploy, click Create deployment in the Deployments section to open the deploy modal.
Deploy modal showing preview toggle, manifest file section, and environment variables section
The modal has two collapsible YAML sections: Manifest File (manifest.yaml) and Environment Variables (environments.yaml).
  • On your first deployment, paste your manifest.yaml and environments.yaml content into the respective sections.
  • On subsequent deployments, both sections pre-populate from the last deployment. You can deploy without expanding them if no changes are needed.
  • Enable the Preview deployment toggle to create an ephemeral deployment with an automatic TTL instead of a production deployment. See Preview Deployments.
Deployments that reference missing secrets will fail during the Helm release phase. Ensure secrets are created in the SGP secret store before deploying. See Secrets.

​
Monitoring a deployment

The build detail page lists all deployments from this build. Reload the page to see status updates.
Build detail page showing multiple deployments with mixed statuses
Production deployments show a gray badge; preview deployments show a purple badge with the PR number and an expiration countdown. Preview deployments are automatically torn down when the TTL expires. Click any deployment row to inspect its event timeline and logs.
Deployment detail page showing metadata, deployment events timeline, and deploy logs section
The Deployment Events section shows the Kubernetes event sequence for the rollout. A successful deployment progresses through: Scheduled → Pulling → Pulled → Created → Started → ScalingReplicaSet → ReleaseSuccessful. The Deploy Logs section shows container runtime output. If the deployment is healthy and the agent produces no stdout on startup, this section may show “No logs available.”

​
Diagnosing a failing deployment

A gap in the event timeline tells you where the problem is:
Last event seenLikely cause
ScheduledImage could not be pulled. Check the image reference and registry access.
PullingImage pull is timing out. Large images or registry rate limits.
StartedHealth check is not passing. Check Deploy Logs for runtime errors.
ScalingReplicaSet (no ReleaseSuccessful)Helm timeout or release hook issue.
If a deployment stays in Deploying longer than expected, check Deployment Events. Missing events after Scheduled usually mean node resource constraints or image pull failures.

​
Diagnosing a failed build

Failed builds show a Failed badge on the build detail page and an Error badge in the Build History list (same state, different labels).
Failed build detail page showing error status and build logs section
The Create deployment button is disabled for failed builds. Check the Build Logs for error output. A short build duration (under 30 seconds) usually points to a configuration error (missing Dockerfile, invalid manifest) rather than a code error. Common causes:
  • Dockerfile not found: manifest.yaml references a path that doesn’t exist in the build context
  • Dependency install failure: pip install, npm install, etc. fails
  • Build context too large: add a .dockerignore to exclude unnecessary files
  • Invalid manifest: syntax errors or invalid field values in manifest.yaml
  • Missing secrets: the manifest references a secret that doesn’t exist
  • Base image unavailable: the Dockerfile’s base image can’t be pulled
  • Timeout: build exceeded the maximum duration
If builds fail repeatedly, verify the agent builds locally first with docker build. This surfaces issues faster than iterating through the cloud pipeline.

​
Next steps