CI/CD integration

Reading time: 0 minute(s) (0 words)

Use sloctl in your continuous integration and continuous delivery (CI/CD) pipeline to manage Nobl9 resources from version-controlled definitions. Validate proposed changes in CI, then apply approved definitions and delete retired resources during deployment. These steps work with any CI/CD platform that can run sloctl and connect to Nobl9.

Terraform

If you want first class state management, execution plans, dependency ordering or drift detection, all out of the box, we highly recommend using Terraform and Nobl9 Terraform provider.

Prepare the pipeline

1. Store your Nobl9 YAML definitions in a version controlled repository, using the layout below.
2. Install sloctl on the runner or use the Docker image. Pin the CLI or image version so pipeline behavior does not change with each release.
   • For GitHub-specific setup, see GitHub Actions.
3. Create Nobl9 access keys with permissions to manage the resources in your target Project. Store the client ID and client secret in your CI/CD platform's secret store.
4. Authenticate the runner, see Configuration and Docker authentication.

Organize the repository

Keep active definitions separate from definitions queued for deletion:

slo-definitions/
├── active/
│   ├── services/
│   │   └── services.yaml
│   └── slos/
│       ├── availability.yaml
│       └── latency.yaml
└── to-delete/
    └── slos/
        └── legacy-availability.yaml

The workflow looks like this:

• to create an SLO, add its definition under active/
• to update an SLO, edit its definition under active/ without changing its name or Project
• to delete an SLO, move its definition from active/ to to-delete/

Keep the full definition when you move it, including its apiVersion, kind, and resource identity in metadata. For example, to queue availability.yaml for deletion:

git mv slo-definitions/active/slos/availability.yaml slo-definitions/to-delete/slos/legacy-availability.yaml

Do not leave the same resource in both folders. The apply step must read only active/, never the parent slo-definitions/ directory. Simply removing a file from the repository does not delete the resource from Nobl9.

Validate changes

Skip a folder's validation and deployment steps when it contains no matching definitions. An unmatched --file glob is an error, not a successful no-op. This includes ordinary runs with no queued deletions and runs after deletion cleanup. The following snippets require Bash 4 or later and run from the repository root. They use recursive glob matching and treat missing or empty folders as empty lists. Use regular directories under both folders, not directory symlinks.

Validate definitions that will be created or updated:

shopt -s nullglob globstar dotglob
definitions=(slo-definitions/active/**/*.yaml)
if (( ${#definitions[@]} > 0 )); then
  sloctl apply --dry-run --yes \
    --file 'slo-definitions/active/**/*.yaml'
fi

Validate queued deletions separately:

shopt -s nullglob globstar dotglob
definitions=(slo-definitions/to-delete/**/*.yaml)
if (( ${#definitions[@]} > 0 )); then
  sloctl delete --dry-run --yes \
    --file 'slo-definitions/to-delete/**/*.yaml'
fi

When definitions exist, both commands send validation requests to Nobl9 without persisting resource changes. They require authentication and network access, so they are not offline YAML checks. Configure the pipeline to fail if either command returns a nonzero exit status.

If other resources reference an SLO queued for deletion, update those references and deploy that change before you submit the deletion.

Apply approved changes

After validation and review, apply the same definitions from the approved commit:

shopt -s nullglob globstar dotglob
definitions=(slo-definitions/active/**/*.yaml)
if (( ${#definitions[@]} > 0 )); then
  sloctl apply --yes \
    --file 'slo-definitions/active/**/*.yaml'
fi

Restrict this step to trusted branches or tags, and use your CI/CD platform's approval controls for production deployments. Keep validation and deployment on the same commit so they use the same definitions.

Delete removed resources

If there are active definitions, apply them first, then process the approved definitions in to-delete/.

Deleting resources

This command deletes resources from Nobl9, not files from the repository.
If deleted, SLO data is permanently lost.

shopt -s nullglob globstar dotglob
definitions=(slo-definitions/to-delete/**/*.yaml)
if (( ${#definitions[@]} > 0 )); then
  sloctl delete --yes \
    --file 'slo-definitions/to-delete/**/*.yaml'
fi

Stop the pipeline if deletion fails. Do not remove queued definitions until you confirm that their resources were deleted.

Verify the deployment

Retrieve the SLO definitions from the target Project:

sloctl get slos --project my-project

Compare the returned definitions with the intended changes. Confirm that active SLOs have the expected configuration and retired SLOs are absent. See the sloctl command reference for other resource types and output options.

Clean up completed deletions

After you verify a successful deletion, remove its definition from to-delete/ in a follow-up commit. For the legacy-availability.yaml example:

git rm slo-definitions/to-delete/slos/legacy-availability.yaml

retaining deleted objects

Do not keep deleted objects in to-delete/ as an archive: a later run could delete a recreated resource with the same identity.

If deployment fails partway through, inspect the state in Nobl9 before retrying. The apply and delete commands are separate operations, not a single transaction.

GitHub Actions

See GitHub Actions for examples using the Nobl9 action or the sloctl Docker image directly.