Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -90,10 +90,10 @@ To setup the PS1(prompt) for bash/zsh, please follow [these instructions](https:
| `ocm backplane managedJob list [flags]` | Retrieve a list of backplane managed job resources |
| `ocm backplane managedJob logs <job_name> [flags]` | Retrieve logs of the specified managed job resource |
| `ocm backplane managedJob delete <job_name> [flags]` | Delete the specified managed job resource |
| `ocm backplane testJob create <script> [flags]` | Create a backplane test managed job on a non-production cluster for testing. To use with bash libraries, make sure the libraries are in the scripts directory in the format `source /managed-scripts/<path-from-managed-scripts-scripts-dir>` |
| `ocm backplane testJob get <job_name> [flags]` | Retrieve a backplane test job resource |
| `ocm backplane testJob list [flags]` | Retrieve a list of backplane test job resources |
| `ocm backplane testJob logs <job_name> [flags]` | Retrieve logs of the specified test job resource |
| `ocm backplane testJob render [flags]` | Render the Kubernetes YAML (ServiceAccount, RBAC and Pod) for a draft managed script locally, so it can be applied directly with `oc apply -f`. See [Testing a draft managed script](docs/testing-managed-scripts.md). |
| `ocm backplane testJob create <script> [flags]` | (Deprecated, use `testJob render` instead) Create a backplane test managed job on a non-production cluster for testing. |
| `ocm backplane testJob get <job_name> [flags]` | (Deprecated, use `testJob render` instead) Retrieve a backplane test job resource |
| `ocm backplane testJob logs <job_name> [flags]` | (Deprecated, use `testJob render` instead) Retrieve logs of the specified test job resource |
| `ocm backplane upgrade` | Upgrade backplane-cli to the latest version |
| `ocm backplane version` | Display the installed backplane-cli version |
| `ocm backplane healthcheck` | Check the VPN and Proxy connectivity on the host network when experiencing isssues accessing the backplane API|
Expand Down
43 changes: 43 additions & 0 deletions docs/testing-managed-scripts.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
# Testing a draft managed script

When developing a new [managed script](https://github.com/openshift/managed-scripts), you often want to run your draft before it is merged.

Previously this was done with `ocm backplane testJob create/get/logs`, which required the backplane API to build and run a test job. Those subcommands are now **deprecated**.

The recommended way is `ocm backplane testJob render`, which generates the Kubernetes YAML (ServiceAccount, RBAC and Pod) for your script **locally** — no backplane API call is made. You then apply it directly on a non-production cluster where you have cluster-admin access.


## Prerequisite
You have a non-production ROSA cluster that you own or control, with cluster-admin permissions to create resources in it. For example, your own cluster with direct cluster-admin access via IDP, or a staging cluster where you have backplane elevation permissions.

## Example

Assuming your draft script lives in a directory that contains a `metadata.yaml` and the script itself (the same layout used in the [managed-scripts](https://github.com/openshift/managed-scripts) repo):

```bash
# 1. Log in to a non-production cluster with cluster-admin access
oc login <cluster-api-url>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clarify the prerequisite here: as we don't use backplane to login but cluster-admin instead.

This cluster-admin access is cluster-specific, right? So this workflow assumes the script author has a non-prod cluster they own/control and can obtain direct cluster-admin credentials rather than picking an random staging fleet cluster as with the old test-script endpoint.

If that's the intended workflow, maybe worth making that explicit in the doc?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. Yeah, that's intended and it is a safe method for testing scripts.

Let me mention this explicitly in the doc.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a new commit with a Prerequisite to mention this.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one more thought, does this intentionally require every script contributor to have their own non-prod cluster with direct cluster-admin access?

For SRE users who already have Backplane access, backplane login + elevate should also work with the rendered YAML, and lets them test on any suitable staging cluster without having to create/own one.

The render command itself is independent of how the kubeconfig is obtained

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think as long as the user have cluster-admin access, either backplane elevation or IDP cluster-admin.

Usually MCS or SRE can create their own cluster with cluster-admin, that's the cleanest way for testing. But sometime they can just borrow a cluster with backplane elevation on staging to test, that will be audited.

I pushed a new commit to make the prerequisite more clear about this. PTAL.


# 2. Render the YAML from your script directory
cd scripts/SREP/example
ocm backplane testJob render -p VAR1=val1 > test-job.yaml

# 3. Review the generated YAML, then apply it
oc apply -f test-job.yaml

# 4. Watch the job and inspect its logs with standard oc commands
oc -n openshift-backplane-managed-scripts get pods
oc -n openshift-backplane-managed-scripts logs <pod-name>

# 5. Clean up after testing
oc delete -f test-job.yaml
```

## Useful flags

| Flag | Description |
| ---- | ----------- |
| `-p, --params 'VAR1=val1'` | Pass parameters to the script (repeatable, e.g. `-p 'VAR1=val1' -p VAR2=val2`). |
| `-s, --source-dir <dir>` | Directory of the script to render (defaults to the current directory). |
| `-i, --base-image-override <img>` | Container image used to run the script. Defaults to the latest managed-scripts image resolved from GitHub. |
| `-o, --output <file>` | Write the rendered YAML to a file instead of stdout. |