-
Notifications
You must be signed in to change notification settings - Fork 87
docs: Update managed-scripts testing method #986
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
+47
−4
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| 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> | ||
|
|
||
| # 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. | | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
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-admininstead.This
cluster-adminaccess is cluster-specific, right? So this workflow assumes the script author has a non-prod cluster they own/control and can obtain directcluster-admincredentials 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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 + elevateshould 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
There was a problem hiding this comment.
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.