Add integration test presubmit for openshift/sippy

[redhat-chai-bot]

What

Adds a new presubmit integration test for openshift/sippy that runs make integration using testcontainers-go with a PostgreSQL container.

How

• Builds a sippy-integration image from Dockerfile.integration (podman + fuse-overlayfs on top of src)
• Uses ci-operator nested_podman: true for user namespace and /dev/fuse access
• The Docker ENTRYPOINT in the image starts rootless podman before running tests
• ENV HOME=/tmp is baked into the image (Set HOME=/tmp in Dockerfile.integration for CI compatibility sippy#3878) so the entrypoint has a writable home directory

Config

- as: integration
  capabilities:
  - nested-podman
  commands: make integration
  container:
    from: sippy-integration
  nested_podman: true
  skip_if_only_changed: ^docs/|\.md$|^(?:.*/)?(?:\.gitignore|OWNERS|PROJECT|LICENSE)$

Generated presubmit

• Job: pull-ci-openshift-sippy-main-integration
• Trigger: /test integration
• Required for PRs, skips doc-only changes

Linked to: TRT-2865

[redhat-chai-bot]

/pj-rehearse auto-ack

---

AI-generated. Review for accuracy.

[coderabbitai]

Walkthrough

The Sippy CI configuration adds a sippy-integration image and an integration test that runs make integration with nested Podman capabilities.

Changes

Sippy integration testing

Layer / File(s)	Summary
Integration image and test wiring ci-operator/config/openshift/sippy/openshift-sippy-main.yaml	The configuration builds sippy-integration from Dockerfile.integration with the src base image. The integration test runs make integration with nested Podman enabled and skips documentation- and metadata-only changes.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• openshift/release#82684: Adds the same Sippy integration image and nested Podman integration test configuration.

Suggested reviewers: smg247

🚥 Pre-merge checks | ✅ 15

✅ Passed checks (15 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names	✅ Passed	The PR changes only CI YAML and generated job names; it adds no Ginkgo It, Describe, Context, or When titles and contains no dynamic test-name values.
Test Structure And Quality	✅ Passed	The PR changes only ci-operator YAML files; no Ginkgo test source or It/BeforeEach/AfterEach/Eventually code is included for this check.
Microshift Test Compatibility	✅ Passed	The commit changes only ci-operator YAML and generated job files; it adds no Ginkgo e2e tests or test bodies requiring MicroShift API compatibility review.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	The PR changes only ci-operator configuration and generated job files; it adds no Ginkgo e2e test source, so SNO compatibility checks are not applicable.
Topology-Aware Scheduling Compatibility	✅ Passed	PR modifies only CI test configuration (ci-operator/config), not deployment manifests, operator code, or controllers. Custom check scope does not apply to test infrastructure changes.
Ote Binary Stdout Contract	✅ Passed	The PR changes only three YAML files; no OTE binary source, process-level entry point, or stdout write exists in the changed files.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	The PR adds only CI YAML and generated job configuration; it adds no Ginkgo test code, IPv4 literals, IP parsing, URLs, or public-network dependency.
No-Weak-Crypto	✅ Passed	The pull request contains only CI-operator YAML configuration changes. No weak cryptographic implementations, algorithms (MD5, SHA1, DES, RC4, 3DES, Blowfish, ECB), or insecure comparisons are intr...
Container-Privileges	✅ Passed	The configuration uses only nested-podman capability for rootless container workloads with documented justification. No privileged flags, hostPID/Network/IPC, SYS_ADMIN, or allowPrivilegeEscalation...
No-Sensitive-Data-In-Logs	✅ Passed	No sensitive data (passwords, tokens, API keys, PII, session IDs, hostnames, or customer data) found in the logging or configuration of the new integration test.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the new integration test presubmit for openshift/sippy.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[openshift-merge-bot]

@redhat-chai-bot: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel.

[smg247]

Did you consider using the .devcontainer/Dockerfile for this? I am not sure if it is missing anything you would need. It seems reasonable to reuse if we are going the nested-podman route. I also see value in making the integration tests work in the same manner the e2e tests do (which doesn't require nested-podman), but I am not convinced on that either.

[redhat-chai-bot]

Good question! Here's the reasoning behind using Dockerfile.integration:

Why not .devcontainer/Dockerfile?
The devcontainer Dockerfile is designed for the VS Code development workflow — it may include tooling (editor extensions, shell config, etc.) that isn't needed in CI and could add unnecessary image build time. Dockerfile.integration was purpose-built for CI in sippy#3866 with just the minimal set: podman, fuse-overlayfs, shadow-utils, subuid/subgid setup, and the entrypoint script that wires up testcontainers-go. That said, I haven't compared them side-by-side — if .devcontainer/Dockerfile already has everything needed, reusing it could reduce maintenance.

Why nested-podman instead of the e2e approach?
The e2e tests use a cluster_claim which provisions a full OCP cluster — that's significantly heavier infrastructure for integration tests that only need to spin up a PostgreSQL container via testcontainers-go. The nested-podman approach gives us rootless podman in the test pod directly, which is a lighter-weight solution.

I'll defer to @smg247 and the PR requester on which approach they prefer — this is a design tradeoff between image reuse vs. purpose-built, and lightweight (nested-podman) vs. consistent-with-e2e (cluster_claim).

---

AI-generated. Review for accuracy.

---

AI-generated. Review for accuracy.

[smg247]

The devcontainer dockerfile does much more than just allow for a VS code development workflow...it handles our staging environment and agentic solve in the repo as well. I think it is suitable for this purpose even if it has a few things included that aren't needed here. It is better to reuse than to create yet another dockerfile for this single job.

[redhat-chai-bot]

That makes sense — thanks for the context. I'll update this PR to use .devcontainer/Dockerfile instead of Dockerfile.integration, pending confirmation from the PR requester.

---

AI-generated. Review for accuracy.

---

AI-generated. Review for accuracy.

[openshift-merge-bot]

@redhat-chai-bot, pj-rehearse: unable to determine affected jobs. This could be due to a branch that needs to be rebased. ERROR:

couldn't prepare candidate: couldn't rebase candidate onto b3ac0827d87cb2089115faa2d9dff88c0f242f49 due to conflicts

Interacting with pj-rehearse

Comment: /pj-rehearse to run up to 5 rehearsals
Comment: /pj-rehearse skip to opt-out of rehearsals
Comment: /pj-rehearse {test-name}, with each test separated by a space, to run one or more specific rehearsals
Comment: /pj-rehearse more to run up to 10 rehearsals
Comment: /pj-rehearse max to run up to 25 rehearsals
Comment: /pj-rehearse auto-ack to run up to 5 rehearsals, and add the rehearsals-ack label on success
Comment: /pj-rehearse list to get an up-to-date list of affected jobs
Comment: /pj-rehearse abort to abort all active rehearsals
Comment: /pj-rehearse network-access-allowed to allow rehearsals of tests that have the restrict_network_access field set to false. This must be executed by an openshift org member who is not the PR author

Once you are satisfied with the results of the rehearsals, comment: /pj-rehearse ack to unblock merge. When the rehearsals-ack label is present on your PR, merge will no longer be blocked by rehearsals.
If you would like the rehearsals-ack label removed, comment: /pj-rehearse reject to re-block merging.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: redhat-chai-bot
Once this PR has been reviewed and has the lgtm label, please assign droslean for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

@redhat-chai-bot: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/openshift-image-mirror-mappings	063cb0b	link	true	/test openshift-image-mirror-mappings
ci/prow/core-valid	063cb0b	link	true	/test core-valid
ci/prow/yamllint	063cb0b	link	true	/test yamllint
ci/prow/check-gh-automation	063cb0b	link	true	/test check-gh-automation
ci/rehearse/openshift/sippy/main/agentic-staging	13a18ae	link	unknown	/pj-rehearse pull-ci-openshift-sippy-main-agentic-staging
ci/prow/generated-config	063cb0b	link	true	/test generated-config
ci/prow/ci-operator-config	063cb0b	link	true	/test ci-operator-config
ci/prow/owners	063cb0b	link	true	/test owners
ci/rehearse/periodic-ci-openshift-sippy-main-agentic-periodic-sippy-pr-followup-agent	13a18ae	link	unknown	/pj-rehearse periodic-ci-openshift-sippy-main-agentic-periodic-sippy-pr-followup-agent
ci/prow/ci-operator-registry	063cb0b	link	true	/test ci-operator-registry
ci/prow/ordered-prow-config	063cb0b	link	true	/test ordered-prow-config
ci/prow/ci-operator-config-metadata	063cb0b	link	true	/test ci-operator-config-metadata
ci/prow/prow-config-filenames	063cb0b	link	true	/test prow-config-filenames
ci/rehearse/periodic-ci-openshift-sippy-main-agentic-periodic-sippy-jira-agent	13a18ae	link	unknown	/pj-rehearse periodic-ci-openshift-sippy-main-agentic-periodic-sippy-jira-agent
ci/prow/release-controller-config	063cb0b	link	true	/test release-controller-config

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.