Inventory
Inventory is the list of Cloud resources in your account and whether they still match what you last applied. Use it to see what exists, who created it, and whether a table, site, or secret has drifted.
Terraform and CDKTF keep that list up to date as they create, update, and delete resources. Call skippr-cloud inventory yourself only when you build a custom provisioner, a resource dashboard, or an explicit drift check.
Status: Preview. See the API action reference for the full command list.
At a glance
| Fact | Value |
|---|---|
| CLI | skippr-cloud inventory <operation> |
| SigV4 service code | inventory |
| Target prefix | CloudInventory. |
| Authentication | Cloud JWT or SigV4 credentials |
| Stored status values | PROVISIONING, READY, FAILED, MISSING, CHANGED |
| Repair owner | Terraform or your direct API workflow |
Inventory does not own Terraform state, produce a plan, or repair a resource. A MISSING or CHANGED status tells you something drifted; you decide how to fix it.
Provider-managed default
The Terraform and CDKTF provider lifecycle keeps inventory aligned:
- Create or import calls
RegisterResource. - A successful mutation calls
UpdateResourceRecord. - Read describes the service resource and calls
VerifyResource. - Delete calls
DeregisterResource.
Terraform still owns desired configuration, plan, refresh, import, and apply decisions. An inventory status of MISSING or CHANGED informs you about observed state; it does not trigger a repair.
Sites Deployments are not registered as provider resources by default. The provider tracks stable cloud_site and cloud_site_domain_binding resources; the Sites API owns immutable Deployment history.
When to call inventory directly
Custom provisioning
Register a resource after your client creates or imports it. Send lastApplied as the catalog observed model for that resource kind. Skippr computes the digest and records the first verification result. Update the record after a successful mutation, and deregister it after deletion.
Resource dashboards
Use GetResource or ListResources to show managed resources, provenance, revision, and last verification state. List pagination uses maxResults and an opaque nextToken.
Explicit drift checks
Use VerifyResource to compare one inventory record with the resource returned by its service describe operation. Use ReportDrift when you also want to persist the newly observed status with optimistic concurrency.
Operations by task
| Task | Operation | Result |
|---|---|---|
| Register after create or import | RegisterResource | Creates or returns the record for the resource identity. |
| Record a successful mutation | UpdateResourceRecord | Updates the last-applied model and revision. |
| Remove after delete | DeregisterResource | Removes the managed-resource record. |
| Inspect one resource | GetResource | Returns the current inventory record. |
| Browse resources | ListResources | Returns a filterable, paginated list. |
| Check actual state | VerifyResource | Describes the service resource and returns the comparison. |
| Check and persist drift | ReportDrift | Re-describes and conditionally stores the verified result. |
Understand status
| Status | Meaning |
|---|---|
PROVISIONING | A create or update is in progress. |
READY | The resource exists and matches the last-applied model within its verification rules. |
FAILED | The last mutation or verification failed. |
MISSING | The inventory record exists, but the service resource was not found. |
CHANGED | The resource exists, but its observed model differs from the last-applied model. |
Verification reads resource state only. It never creates, updates, deletes, or repairs the resource.
Identity and record contract
The resource identity is resourceType and physicalId. Skippr records the creator from the signed-in session.
A record can include timestamps, revision, desired-model digest, lastApplied, last verification details, and optional provider, stack, and workspace provenance.
ReportDrift accepts resourceType, physicalId, and the current revision. It re-runs the service describe operation instead of trusting a caller-supplied status, digest, or detail. A successful write increments revision; a stale revision returns ConflictException.
Limits, errors, and contracts
ListResourcesis paginated withmaxResultsand opaquenextToken; use the operation schema for accepted bounds.- Registration is idempotent for the same resource type and physical id.
- Concurrent record writes require the current revision where the operation schema defines it.
- Common errors are
ResourceNotFoundException,ConflictException,ValidationException, andInternalException, using the shared Cloud error body. - Request and response schemas are in the API actions.