Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

🚀 Build Images Ready

Images are ready for commit f6b3c44. To use with deploy scripts:

export MAIN_IMAGE_TAG=4.11.x-1130-gf6b3c44a6c

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 @coderabbitai help to get the list of available commands and usage tips.}

[Claude writing on behalf of @gualvare]

Regarding the uuidgen nitpick: skipping this. uuidgen ships with macOS and virtually all Linux distros (part of util-linux). The code examples in this skill are illustrative, not copy-paste scripts — the agent executing the skill can handle tool availability on its own. Adding a fallback would be overengineering for a skill document.

All three major findings (shell variables, export block, crane --platform) were fixed in 95dfaae. CodeRabbit reviewed an older commit (fa027c0) — the current HEAD (001b2ac) has all these addressed.

@guzalv
Would it be too out-of-scope to include the option to give this skill a PR build reference, instead of having it build the image locally?

@guzalv Would it be too out-of-scope to include the option to give this skill a PR build reference, instead of having it build the image locally?

@vjwilson thanks! That is a use case I had not thought of "verify someone else's PR", or "verify something that AI generated before having verified it first".

The main focus of the skill is to verify before creating a PR at all and that way iterate faster, save time spent on checking CI failures, save CI costs. And from that point of view building locally is the right approach.

But what you suggest is also valid and many steps are shared. So I have added support for using PR image builds in d7e10ce

Test in ambient:

PASS — the CI fast-path worked. The agent:
Checked out the PR branch, found no local changes
Found the CI bot comment with MAIN_IMAGE_TAG=4.11.x-1099-gaad2d04064
Verified it matched HEAD — skipped build and crane push entirely
Deployed using the CI image directly
Ran before/after unit tests comparing base vs PR behavior
Confirmed the fix works: timeout and cancellation no longer delete compliance results
It even did a full fresh deploy from scratch and ran a proper before/after comparison. 66 tool calls, ~10 minutes. No user prompts needed.
The fast-path is working as designed — when CI has already built the image, there's no need to rebuild locally.

This looks great, but I think there's a lot of overlap with roxie, and you could remove ~300 lines from the skill by using it instead. The following is an AI generated report:

We have an internal developer tool (roxie) that already handles most of the cluster setup and deployment logic in this skill. We're also in the process of replacing CI shell scripts with roxie, so it would be good to align this skill with that direction rather than reimplementing the same logic in markdown.

Specifically, these phases could delegate to roxie instead of rolling their own shell sequences:

Phase 0 (Prerequisites Check) — ~40 of 62 lines

• Cluster tool detection, registry auth probing, and image verification are all handled by roxie automatically.
• The crane/ttl.sh fallback logic for the image-mutation path is novel and should stay.

Phase 1 (Discover Cluster) — all 33 lines

• Roxie auto-detects cluster type (GKE, OpenShift, Kind, Minikube, K3s, CRC), context, and node architecture. A single roxie env replaces this entire phase.

Phase 2 (Find StackRox and Authenticate) — all 206 lines

• 2a/2b (namespace detection, endpoint discovery, credential management): Roxie handles endpoint wiring and admin password generation/retrieval automatically.
• 2c (deploy from scratch): This is the biggest concern — 130 lines of fragile shell that hardcodes Quay tag resolution, roxctl ldflags (including the ScannerVersion workaround), 15+ env vars, and post-deploy image fixups for scanner-v4-db. All of this is a single roxie deploy both. This section is the most
  likely to rot as deployment internals change.

Phase 6 (Deploy) — ~15 of 59 lines

• Health checks, rollout waiting, and port-forward management overlap with roxie's built-in wait and port-forward logic.

Total: ~294 of 721 lines (41%) could be replaced by shelling out to roxie for cluster setup and deployment, while keeping the genuinely novel parts of this skill: change analysis, crane-based image mutation, test execution, and proof generation.

I'd like to second what @vladbologa said.

The purpose of roxie is to provide modern, flexible, operator-based ACS deployment capabilities specifically designed for the use-cases of engineers. This will allow us to get rid of the deployment shell scripts -- work is underway to integrate roxie there as we speak.

Building something new on top of the deploy shell scripts nowadays instead of just using what we have build during the last months, suggests that I didn't do a good job in sharing project status updates on roxie. :-(

Remaining features targeted at what ACS engineers expect from roxie are in the process of being implemented right now. If there is anything missing that you (or anyone from the team) needs, please tell us. Or if there is anything else holding you back from adopting roxie, please tell us.

Sharing the link again:
https://github.com/stackrox/roxie

@guzalv this discussion shows how many of us have different preferences regarding the art of everyday ACS developer work. That is why I only selectively publish my skills and I do that outside of the stackrox repo.

Thanks @vladbologa and @mclasmeier! I have refactored the skill to use roxie, tested it and it works perfectly. I passed your analysis to Claude, and after it did several trials it settled down for an approach where it used Roxie mostly as suggested, but kept certain existing bits. I asked it to update the PR description with details. Would you like to see if that makes sense?

I think you’ve done a good job at marketing roxie because I was aware it exists, it’s on my side that I didn’t “internalize” it so to say.

Some background in case you’re interested: when I joined I got a powerful machine which builds images faster than CI, so I looked into deploying those. Found the deploy/ scripts, and then ended up rolling my own set of scripts to build/push/deploy tailored to my workflow in part because I thought that would provide insight into install methods, which it did.

Then I heard about roxie several times, and while I found it superior and wanted to look into it I never actually did it, and still kept my workflow because “it works”.

When I started using agents to deploy stackrox, I told them to use those scripts because I’m familiar with them so I could babysit the agent and iterate on a better prompt/skill.

When we discussed in the team about sharing agentic workflows I thought of sharing this, which is serving me very well, because I didn’t see it anywhere else. But instead of having the skill use my own scripts I told it to use the deploy/ framework: end result would be the same, and it would easier on other people’s eyes who bothered to read it.

At that point I should have gone with roxie, but it just didn’t come to my mind, I guess because what my scripts replace is the deploy/ framework, not roxie.

@vikin91 I think this shows quite well the beauty of collaborating on aspects that are needed by many people: I proposed something, got feedback, adapted, and when it gets merged everyone will have the opportunity to automatically use the best solution transparently, and learn about it if they are interested. I see skills as equivalent to scripts in "the old times" :D : some make sense within projects and others outside.

Moving this skill to the stackrox/skills marketplace so it can be installed via /plugin menu without merging into the main repo. Closing this PR.