-
Notifications
You must be signed in to change notification settings - Fork 78
SANDBOX-1561 | feature: Make targets for debugging services and operators #1242
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
base: master
Are you sure you want to change the base?
SANDBOX-1561 | feature: Make targets for debugging services and operators #1242
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: MikelAlejoBR The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
WalkthroughAdds a debug-focused E2E local deployment flow: a new Makefile target exports Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Dev as Developer (IDE)
participant Make as Makefile (`dev-deploy-e2e-local-debug`)
participant CI as CI scripts (`manage-*.sh`)
participant OC as OpenShift (kubectl/oc)
participant CSV as ClusterServiceVersion
participant Pod as Operator Pod (with Delve)
Note right of Make: Trigger debug flow\nexports DEBUG_MODE=true
Dev->>Make: run dev-deploy-e2e-local-debug
Make->>CI: call image build/push with DEBUG_MODE
CI->>CI: compute DEBUG_MODE_SUFFIX, invoke make push target
CI->>OC: apply operator images/manifests
Make->>OC: patch CSVs for host/member (replace cmd/args -> Delve)
OC->>CSV: update CSV containers
CSV->>Pod: rollout operator pods with Delve enabled
Dev->>Pod: port-forward 50000 -> connect debugger
Note over Pod,Dev: Debugging session established
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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.
Actionable comments posted: 0
🧹 Nitpick comments (3)
scripts/ci/manage-operator.sh (1)
47-62: Good implementation of debug mode support.The conditional logic correctly enables debug-mode image builds by appending
-debugto the make target whenDEBUG_MODEis"true". This allows the downstream make targets to build Delve-enabled images.Optional: standardize indentation
The indentation within the if-else block is inconsistent. Consider aligning for better readability:
push_image() { # When the "${DEBUG_MODE}" argument is passed, we instruct Make to push # the "debug" images with Delve on them. if [[ $1 == "true" ]]; then - DEBUG_MODE_SUFFIX="-debug" - else - DEBUG_MODE_SUFFIX="" + DEBUG_MODE_SUFFIX="-debug" + else + DEBUG_MODE_SUFFIX="" fimake/dev.mk (2)
54-55: Consider renaming CVS to CSV for clarity.The variable names use "CVS" but the resource type is "ClusterServiceVersion," commonly abbreviated as "CSV." Using "CSV" would be clearer and avoid confusion with the legacy version control system.
Suggested naming improvement
# Get the CVSs for the host and member operators, in order to be able to # patch them. - HOST_CVS_NAME=$$(oc get --namespace "${DEFAULT_HOST_NS}" --output name ClusterServiceVersion) - MEMBER_CVS_NAME=$$(oc get --namespace ${DEFAULT_MEMBER_NS} --output name ClusterServiceVersion) + HOST_CSV_NAME=$$(oc get --namespace "${DEFAULT_HOST_NS}" --output name ClusterServiceVersion) + MEMBER_CSV_NAME=$$(oc get --namespace ${DEFAULT_MEMBER_NS} --output name ClusterServiceVersion)Then update references on lines 61, 69, and 70 accordingly.
69-70: Consider improving readability of long patch commands.The JSON patch commands are very long (200+ characters), making them difficult to review and maintain. While the logic appears correct, consider breaking them into variables or using here-documents for better readability.
Example: Extract patch JSON to variables
+ # Define patch for host operator + HOST_PATCH='[{"op": "replace", "path": "/spec/install/spec/deployments/0/spec/template/spec/containers/1/args", "value": []}, {"op": "replace", "path": "/spec/install/spec/deployments/0/spec/template/spec/containers/1/command", "value": ["dlv", "--listen=:50000", "--headless", "--continue", "--api-version=2", "--accept-multiclient", "exec", "/usr/local/bin/host-operator", "--", "--health-probe-bind-address=:8081", "--metrics-bind-address=127.0.0.1:8080", "--leader-elect"]}]' + + # Define patch for member operator + MEMBER_PATCH='[{"op": "replace", "path": "/spec/install/spec/deployments/0/spec/template/spec/containers/0/args", "value": []}, {"op": "replace", "path": "/spec/install/spec/deployments/0/spec/template/spec/containers/0/command", "value": ["dlv", "--listen=:50000", "--headless", "--continue", "--api-version=2", "--accept-multiclient", "exec", "/usr/local/bin/member-operator", "--", "--health-probe-bind-address=:8081", "--metrics-bind-address=127.0.0.1:8080", "--leader-elect"]}]' + # Patch the host-operator and member-operator CSVs to make them run with # Delve. - oc patch --namespace "${DEFAULT_HOST_NS}" "${HOST_CVS_NAME}" --type='json' --patch='[{"op": "replace", "path": "/spec/install/spec/deployments/0/spec/template/spec/containers/1/args", "value": []}, {"op": "replace", "path": "/spec/install/spec/deployments/0/spec/template/spec/containers/1/command", "value": ["dlv", "--listen=:50000", "--headless", "--continue", "--api-version=2", "--accept-multiclient", "exec", "/usr/local/bin/host-operator", "--", "--health-probe-bind-address=:8081", "--metrics-bind-address=127.0.0.1:8080", "--leader-elect"]}]' - oc patch --namespace "${DEFAULT_MEMBER_NS}" "${MEMBER_CVS_NAME}" --type='json' --patch='[{"op": "replace", "path": "/spec/install/spec/deployments/0/spec/template/spec/containers/0/args", "value": []}, {"op": "replace", "path": "/spec/install/spec/deployments/0/spec/template/spec/containers/0/command", "value": ["dlv", "--listen=:50000", "--headless", "--continue", "--api-version=2", "--accept-multiclient", "exec", "/usr/local/bin/member-operator", "--", "--health-probe-bind-address=:8081", "--metrics-bind-address=127.0.0.1:8080", "--leader-elect"]}]' + oc patch --namespace "${DEFAULT_HOST_NS}" "${HOST_CVS_NAME}" --type='json' --patch="$${HOST_PATCH}" + oc patch --namespace "${DEFAULT_MEMBER_NS}" "${MEMBER_CVS_NAME}" --type='json' --patch="$${MEMBER_PATCH}"
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
README.adocmake/dev.mkscripts/ci/manage-host-operator.shscripts/ci/manage-member-operator.shscripts/ci/manage-operator.sh
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-12-11T16:29:34.403Z
Learnt from: rsoaresd
Repo: codeready-toolchain/toolchain-e2e PR: 1232
File: make/devsandbox-dashboard.mk:57-57
Timestamp: 2025-12-11T16:29:34.403Z
Learning: In make/devsandbox-dashboard.mk, the test-devsandbox-dashboard-e2e-local target intentionally allows PUBLISH_UI=true and DEPLOY_UI=true to enable publishing and deploying when running locally (outside a container), while test-devsandbox-dashboard-in-container sets PUBLISH_UI=false because image pushing is not available from inside the container.
Applied to files:
make/dev.mkREADME.adoc
🧬 Code graph analysis (2)
scripts/ci/manage-host-operator.sh (1)
scripts/ci/manage-operator.sh (1)
push_image(47-62)
scripts/ci/manage-member-operator.sh (1)
scripts/ci/manage-operator.sh (1)
push_image(47-62)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Build & push operator bundles & dashboard image for e2e tests
- GitHub Check: Unit Tests
🔇 Additional comments (5)
scripts/ci/manage-host-operator.sh (1)
99-99: LGTM! DEBUG_MODE propagation is correct.The
push_imagecalls now correctly propagate theDEBUG_MODEenvironment variable to enable debug-enabled image builds when set. The variable is expected to be exported by the caller (e.g.,make/dev.mk), and if unset, the function will default to the standard non-debug build path.Also applies to: 111-111
scripts/ci/manage-member-operator.sh (1)
98-98: LGTM! Consistent with host operator changes.The
push_imageinvocation correctly propagatesDEBUG_MODEto enable debug builds, matching the pattern established inmanage-host-operator.sh.README.adoc (1)
154-161: Excellent documentation for the debug target.The documentation clearly explains the new debugging workflow, including:
- Build characteristics (no optimizations, Delve included)
- Debugger port (50000)
- Port-forwarding instructions
- List of debuggable services
This will help developers quickly understand and use the debugging feature.
make/dev.mk (2)
42-50: Good use of export for DEBUG_MODE propagation.The target correctly exports
DEBUG_MODE=trueto enable debug builds in downstream make targets and shell scripts. The.ONESHELL:directive appropriately enables multi-line shell commands for the complex patching logic that follows.
61-61: Verify: Silent failure handling may hide errors.The
|| truesilently ignores failures when patching the registration service command. If the CSV doesn't exist or the patch path is invalid, this will fail silently and the registration service won't be configured for debugging.Consider whether this should fail loudly or if the silent handling is intentional (e.g., for cases where the CSV structure differs).
Would it be better to check if the patch succeeded and provide a warning, or is silent failure acceptable here?
Adds a new Make target which triggers build in the underlying services and operators which end up building the images without any code optimizations and with Delve on them. Once pushed and deployed to the local OpenShift cluster, it patches the host operator, the member operator and the registration service to launch them with the Delve executable, which allows debugging them on port 50000 after port-forwarding to those pods. SANDBOX-1561
bf2dec3 to
b390515
Compare
|
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.
Actionable comments posted: 2
🧹 Nitpick comments (1)
make/dev.mk (1)
54-55: Verify CSV retrieval when multiple CSVs exist.The command
oc get --output name ClusterServiceVersionreturns all CSVs in the namespace. If there are multiple CSVs (e.g., from previous deployments or other operators), the variable will contain multiple names, potentially causing the subsequentoc patchcommands to fail or behave unexpectedly.Consider filtering for the specific operator CSV:
Suggested improvement
- HOST_CSV_NAME=$$(oc get --namespace "${DEFAULT_HOST_NS}" --output name ClusterServiceVersion) - MEMBER_CSV_NAME=$$(oc get --namespace ${DEFAULT_MEMBER_NS} --output name ClusterServiceVersion) + HOST_CSV_NAME=$$(oc get --namespace "${DEFAULT_HOST_NS}" --output name ClusterServiceVersion | grep toolchain-host-operator) + MEMBER_CSV_NAME=$$(oc get --namespace "${DEFAULT_MEMBER_NS}" --output name ClusterServiceVersion | grep toolchain-member-operator)
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
README.adocmake/dev.mkscripts/ci/manage-host-operator.shscripts/ci/manage-member-operator.shscripts/ci/manage-operator.sh
🚧 Files skipped from review as they are similar to previous changes (1)
- scripts/ci/manage-host-operator.sh
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: rsoaresd
Repo: codeready-toolchain/toolchain-e2e PR: 1232
File: make/devsandbox-dashboard.mk:57-57
Timestamp: 2025-12-11T16:29:34.403Z
Learning: In make/devsandbox-dashboard.mk, the test-devsandbox-dashboard-e2e-local target intentionally allows PUBLISH_UI=true and DEPLOY_UI=true to enable publishing and deploying when running locally (outside a container), while test-devsandbox-dashboard-in-container sets PUBLISH_UI=false because image pushing is not available from inside the container.
📚 Learning: 2025-12-11T16:29:34.403Z
Learnt from: rsoaresd
Repo: codeready-toolchain/toolchain-e2e PR: 1232
File: make/devsandbox-dashboard.mk:57-57
Timestamp: 2025-12-11T16:29:34.403Z
Learning: In make/devsandbox-dashboard.mk, the test-devsandbox-dashboard-e2e-local target intentionally allows PUBLISH_UI=true and DEPLOY_UI=true to enable publishing and deploying when running locally (outside a container), while test-devsandbox-dashboard-in-container sets PUBLISH_UI=false because image pushing is not available from inside the container.
Applied to files:
make/dev.mkREADME.adoc
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: GolangCI Lint
- GitHub Check: Unit Tests
- GitHub Check: Build & push operator bundles & dashboard image for e2e tests
🔇 Additional comments (4)
scripts/ci/manage-member-operator.sh (1)
98-98: LGTM!The change correctly passes
DEBUG_MODEtopush_image, aligning with the pattern inmanage-host-operator.sh. WhenDEBUG_MODEis unset or empty,push_imagewill default to the non-debug push target, which is the expected behavior.README.adoc (1)
154-160: LGTM!The documentation clearly explains the new
dev-deploy-e2e-local-debugtarget, including its purpose, how to connect (port-forwarding on 50000), and which services are debuggable. This aligns with the implementation inmake/dev.mk.make/dev.mk (2)
69-70: Hardcoded container indices may be fragile.The patches use fixed indices (
containers/1for host-operator,containers/0for member-operator). If the container order in the CSV deployment spec changes, the wrong container will be patched.This is acceptable for a dev-only debugging target, but be aware that changes to the operator CSV structures could silently break this functionality.
42-50: Good use of.ONESHELLand exported variable.The
.ONESHELLdirective correctly ensures shell variables persist across recipe lines, andexport DEBUG_MODE=trueproperly propagates the flag to downstream Make invocations viadev-deploy-e2e-local.
| # service should be run with. The command simply adds an environment | ||
| # variable to the operator which then makes sure that the registration | ||
| # service is run with Delve, in case the user wants to connect to it. | ||
| oc patch --namespace "${DEFAULT_HOST_NS}" "${HOST_CSV_NAME}" --type='json' --patch='[{"op": "add", "path": "/spec/install/spec/deployments/0/spec/template/spec/containers/1/env/-", "value": {"name": "REGISTRATION_SERVICE_COMMAND", "value": "[\"dlv\", \"--listen=:50000\", \"--headless\", \"--continue\", \"--api-version=2\", \"--accept-multiclient\", \"exec\", \"/usr/local/bin/registration-service\"]"}}]' || true |
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.
The || true suppresses all errors, including legitimate failures.
While this may be intentional to handle cases where the env var already exists, it also hides real problems like malformed JSON patches or connectivity issues. Consider checking for the specific error condition or removing the fallback if this patch is required for debugging to work.
| push_image() { | ||
| # When the "${DEBUG_MODE}" argument is passed, we instruct Make to push | ||
| # the "debug" images with Delve on them. | ||
| if [[ $1 == "true" ]]; then | ||
| DEBUG_MODE_SUFFIX="-debug" | ||
| else | ||
| DEBUG_MODE_SUFFIX="" | ||
| fi | ||
|
|
||
| GIT_COMMIT_ID=$(git --git-dir=${REPOSITORY_PATH}/.git --work-tree=${REPOSITORY_PATH} rev-parse --short HEAD) | ||
| IMAGE_LOC=quay.io/codeready-toolchain/${REPOSITORY_NAME}:${GIT_COMMIT_ID} | ||
| if is_provided_or_paired; then | ||
| IMAGE_BUILDER=${IMAGE_BUILDER:-"podman"} | ||
| make -C ${REPOSITORY_PATH} ${IMAGE_BUILDER}-push QUAY_NAMESPACE=${QUAY_NAMESPACE} IMAGE_TAG=${TAGS} | ||
| make -C ${REPOSITORY_PATH} ${IMAGE_BUILDER}-push${DEBUG_MODE_SUFFIX} QUAY_NAMESPACE=${QUAY_NAMESPACE} IMAGE_TAG=${TAGS} | ||
| IMAGE_LOC=quay.io/${QUAY_NAMESPACE}/${REPOSITORY_NAME}:${TAGS} | ||
| fi | ||
| } |
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.
🧩 Analysis chain
🏁 Script executed:
# First, understand the repo structure and the manage-operator.sh script
git ls-files | head -20Repository: codeready-toolchain/toolchain-e2e
Length of output: 591
🏁 Script executed:
# Look at the manage-operator.sh script to understand what repos it references
cat -n scripts/ci/manage-operator.sh | head -100Repository: codeready-toolchain/toolchain-e2e
Length of output: 4890
🏁 Script executed:
# Search for any Makefile targets related to "push-debug"
rg 'push-debug|push.*debug' --type=make -nRepository: codeready-toolchain/toolchain-e2e
Length of output: 59
🏁 Script executed:
# Also check for any docker or podman push targets
rg 'docker-push|podman-push' --type=make -nRepository: codeready-toolchain/toolchain-e2e
Length of output: 59
🏁 Script executed:
# Check if there are external repo references or documentation
rg 'host-operator|member-operator' -n | head -20Repository: codeready-toolchain/toolchain-e2e
Length of output: 4535
🌐 Web query:
host-operator repository Makefile docker-push-debug target
💡 Result:
Do you mean the host-operator in the codeready-toolchain GitHub repo (github.com/codeready-toolchain/host-operator)? If so, do you want me to (a) show the Makefile section for the docker-push-debug target, (b) explain what that target does, or (c) locate a different host-operator repo?
🌐 Web query:
member-operator repository Makefile podman-push-debug target
💡 Result:
Which repository do you mean (link or org/name)? I can then fetch its Makefile and explain the podman-push-debug target or how to run it.
🌐 Web query:
codeready-toolchain host-operator Makefile push-debug target site:github.com
💡 Result:
Do you want me to find the exact Makefile "push-debug" target inside the codeready-toolchain/host-operator GitHub repo (and show its contents)? If so I’ll search GitHub and return the file location and snippet.
🌐 Web query:
site:github.com/codeready-toolchain/host-operator Makefile
💡 Result:
I found the repository and its Makefile in the codeready-toolchain/host-operator repo on GitHub: https://github.com/codeready-toolchain/host-operator (Makefile listed in the repo root). [1]
Would you like me to fetch and show the Makefile contents?
🌐 Web query:
site:github.com/codeready-toolchain/member-operator Makefile push
💡 Result:
The repo’s Makefile provides image-push targets — notably podman-push and push-to-quay-staging. The README instructs running:
- make podman-push QUAY_NAMESPACE=codeready-toolchain
- make push-to-quay-staging QUAY_NAMESPACE=codeready-toolchain. [1][2]
Sources:
[1] codeready-toolchain/member-operator README (Makefile push instructions).
[2] codeready-toolchain/member-operator Makefile (repository).
🌐 Web query:
"push-debug" OR "docker-push-debug" OR "podman-push-debug" site:github.com/codeready-toolchain/host-operator
💡 Result:
I searched the codeready-toolchain/host-operator repository for "push-debug", "docker-push-debug", and "podman-push-debug" and found no matches. Would you like me to (a) search all of GitHub for those terms, or (b) search the repository for similar/related build or push targets (e.g., Makefile, scripts, GitHub Actions)?
🌐 Web query:
"push-debug" OR "docker-push-debug" OR "podman-push-debug" site:github.com/codeready-toolchain/member-operator
💡 Result:
I searched the codeready-toolchain/member-operator repository and found no matches for "push-debug", "docker-push-debug", or "podman-push-debug". (github.com)
Citations:
The debug push targets do not exist in the operator repositories. This implementation will fail at runtime.
The docker-push-debug and podman-push-debug make targets referenced on line 59 do not exist in either the host-operator or member-operator repositories. When push_image() is called with the first argument set to "true", the make command will fail because the target ${IMAGE_BUILDER}-push-debug is undefined.
Either:
- Add the
docker-push-debugandpodman-push-debugtargets to the operator Makefiles, or - Remove the debug mode suffix logic from this function and handle debug builds separately
🧰 Tools
🪛 Shellcheck (0.11.0)
[warning] 60-60: IMAGE_LOC appears unused. Verify use (or export if used externally).
(SC2034)
🤖 Prompt for AI Agents
In scripts/ci/manage-operator.sh around lines 47 to 62, the function push_image
builds a make target with a "-debug" suffix when the first arg is "true", but
those docker-push-debug/podman-push-debug targets do not exist causing runtime
failures; remove the DEBUG_MODE_SUFFIX logic so the make invocation always calls
the existing ${IMAGE_BUILDER}-push target (and leave debug-image handling to a
separate, explicit flow), or alternatively add a guard that only appends
"-debug" when the target actually exists; update the function to use a single
known target (or perform an explicit conditional to call a separate debug build
routine) and ensure IMAGE_LOC/IMAGE_TAG logic remains correct.
|
|
||
| if [[ ${PUBLISH_OPERATOR} == "true" ]]; then | ||
| push_image | ||
| push_image "${DEBUG_MODE}" |
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.
Wonder whether this should be added as an option for consistency with other options or it's fine to treat it as a special environment variable.
@MatousJobanek and @rsoaresd may have thoughts on this



Adds a new Make target which triggers build in the underlying services and operators which end up building the images without any code optimizations and with Delve on them.
Once pushed and deployed to the local OpenShift cluster, it patches the host operator, the member operator and the registration service to launch them with the Delve executable, which allows debugging them on port 50000 after port-forwarding to those pods.
Related PRs
Jira ticket
[SANDBOX-1561]
Summary by CodeRabbit
New Features
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.