OSAC-3504: Onboard osac-project/osac

[eliorerz]

osac-project/osac is a new mono-repo consolidating three existing OSAC components (fulfillment-service, osac-operator, osac-aap have already been merged into it; more are planned). It currently has no Prow config in this repo at all -- no tide/lgtm/approve/jira-lifecycle-plugin gating -- unlike every other repo in the org, including the very standalone repos it's replacing.

Adds core-services/prow/02_config/osac-project/osac/{_prowconfig.yaml,_pluginconfig.yaml,OWNERS}, mirroring osac-operator's existing config with the repo name substituted (verified fulfillment-service/osac-operator/osac-aap all use an identical pattern, so there's nothing component-specific to reconcile). OWNERS is seeded from osac-project/osac's current root OWNERS, with non-openshift-org-member logins filtered out to match how the existing per-repo OWNERS files here are generated.

Verified core-services/jira-lifecycle-plugin/config.yaml already covers osac-project via an org-wide wildcard (repos: '*'), so no per-repo Jira project config is needed there.

Ran make prow-config (determinize-prow-config) locally against these new files -- zero diff, confirming they're already in canonical generated form.

One open question for reviewers: does onboarding a repo this way (hand-authored config mirroring an existing sibling) fully cover everything a brand-new repo needs, or does a repo also require webhook/GitHub App provisioning that the interactive make new-repo (repo-init) tool would normally set up and that this PR doesn't touch? osac-project/osac isn't entirely new to GitHub (it's been live for a while), but I want to confirm rather than assume this PR alone is sufficient to produce live gating.

Summary by CodeRabbit

Adds Prow configuration to onboard osac-project/osac into OpenShift CI. The configuration defines repository ownership, approval and LGTM policies, Jira validation, Tide gating, plugins, and trusted trigger applications.

The configuration mirrors the existing osac-operator setup and uses repository-specific ownership. make prow-config produced no diff after generation.

[coderabbitai]

Walkthrough

Added Prow configuration for osac-project/osac. The configuration defines repository ownership, approval and LGTM behavior, external plugins, trusted trigger applications, and Tide label requirements.

Changes

OSAC Prow configuration

Layer / File(s)	Summary
Repository ownership and merge policy core-services/prow/02_config/osac-project/osac/OWNERS, core-services/prow/02_config/osac-project/osac/_prowconfig.yaml	Added approver and reviewer assignments. Added Tide requirements for approval, Jira references, LGTM, and disqualifying labels.
Prow plugins and trusted triggers core-services/prow/02_config/osac-project/osac/_pluginconfig.yaml	Configured approval and LGTM behavior, eight external plugins, enabled Prow plugins, and trusted trigger applications.

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

🚥 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 OWNERS and Prow YAML files; the changed paths contain no Ginkgo test declarations or dynamic test titles.
Test Structure And Quality	✅ Passed	The pull request adds only OWNERS and YAML configuration files. It adds no Ginkgo It blocks or cluster-interacting test code to review.
Microshift Test Compatibility	✅ Passed	The PR adds only three Prow YAML/OWNERS files; the full diff contains no Ginkgo tests, OpenShift API references, or MicroShift-incompatible assumptions.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	The pull request adds only Prow YAML and OWNERS files; it adds no Ginkgo e2e tests or other test changes requiring SNO compatibility review.
Topology-Aware Scheduling Compatibility	✅ Passed	The patch adds only Prow YAML and OWNERS files; it adds no deployment manifests, operator code, controllers, replicas, affinity, topology spread, selectors, tolerations, or PDBs.
Ote Binary Stdout Contract	✅ Passed	The patch adds only three YAML/OWNERS configuration files; it contains no executable OTE source, suite setup, or stdout-writing code.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	The patch adds only OWNERS and Prow YAML configuration; it adds no Ginkgo e2e tests, IPv4 assumptions, or external connectivity requirements.
No-Weak-Crypto	✅ Passed	The three added Prow files contain only YAML/OWNERS metadata, plugin names, URLs, labels, and usernames; no weak algorithms, custom crypto, or secret comparisons were found.
Container-Privileges	✅ Passed	The PR adds only OWNERS and Prow configuration YAML; privilege-key searches and recursive YAML inspection found no privileged, host namespace, SYS_ADMIN, or escalation settings.
No-Sensitive-Data-In-Logs	✅ Passed	The three added files are Prow configuration and OWNERS data; they contain no logging statements or logged credentials, PII, session IDs, customer data, or sensitive hostnames.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the onboarding of the osac-project/osac repository, which is the main change in the pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

[openshift-merge-bot]

[REHEARSALNOTIFIER]
@eliorerz: no rehearsable tests are affected by this change

Note: If this PR includes changes to step registry files (ci-operator/step-registry/) and you expected jobs to be found, try rebasing your PR onto the base branch. This helps pj-rehearse accurately detect changes when the base branch has moved forward.

[openshift-ci-robot]

@eliorerz: This pull request references OSAC-3504 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "5.0.0" version, but no target version was set.

Details

In response to this:

osac-project/osac is a new mono-repo consolidating three existing OSAC components (fulfillment-service, osac-operator, osac-aap have already been merged into it; more are planned). It currently has no Prow config in this repo at all -- no tide/lgtm/approve/jira-lifecycle-plugin gating -- unlike every other repo in the org, including the very standalone repos it's replacing.

Adds core-services/prow/02_config/osac-project/osac/{_prowconfig.yaml,_pluginconfig.yaml,OWNERS}, mirroring osac-operator's existing config with the repo name substituted (verified fulfillment-service/osac-operator/osac-aap all use an identical pattern, so there's nothing component-specific to reconcile). OWNERS is seeded from osac-project/osac's current root OWNERS, with non-openshift-org-member logins filtered out to match how the existing per-repo OWNERS files here are generated.

Verified core-services/jira-lifecycle-plugin/config.yaml already covers osac-project via an org-wide wildcard (repos: '*'), so no per-repo Jira project config is needed there.

Ran make prow-config (determinize-prow-config) locally against these new files -- zero diff, confirming they're already in canonical generated form.

One open question for reviewers: does onboarding a repo this way (hand-authored config mirroring an existing sibling) fully cover everything a brand-new repo needs, or does a repo also require webhook/GitHub App provisioning that the interactive make new-repo (repo-init) tool would normally set up and that this PR doesn't touch? osac-project/osac isn't entirely new to GitHub (it's been live for a while), but I want to confirm rather than assume this PR alone is sufficient to produce live gating.

Summary by CodeRabbit

Adds Prow configuration to onboard osac-project/osac into OpenShift CI. The configuration defines repository ownership, approval and LGTM policies, Jira validation, Tide gating, plugins, and trusted trigger applications.

The configuration mirrors the existing osac-operator setup and uses repository-specific ownership. make prow-config produced no diff after generation.

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

@eliorerz: all tests passed!

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.

[oourfali]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: eliorerz, oourfali

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

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

[openshift-ci]

@eliorerz: Updated the following 2 configmaps:

• config configmap in namespace ci at cluster core-ci using the following files:
  • key core-services-prow-02_config-osac-project-osac-_prowconfig.yaml using file core-services/prow/02_config/osac-project/osac/_prowconfig.yaml
• config configmap in namespace ci at cluster app.ci using the following files:
  • key core-services-prow-02_config-osac-project-osac-_prowconfig.yaml using file core-services/prow/02_config/osac-project/osac/_prowconfig.yaml

Details

In response to this:

osac-project/osac is a new mono-repo consolidating three existing OSAC components (fulfillment-service, osac-operator, osac-aap have already been merged into it; more are planned). It currently has no Prow config in this repo at all -- no tide/lgtm/approve/jira-lifecycle-plugin gating -- unlike every other repo in the org, including the very standalone repos it's replacing.

Adds core-services/prow/02_config/osac-project/osac/{_prowconfig.yaml,_pluginconfig.yaml,OWNERS}, mirroring osac-operator's existing config with the repo name substituted (verified fulfillment-service/osac-operator/osac-aap all use an identical pattern, so there's nothing component-specific to reconcile). OWNERS is seeded from osac-project/osac's current root OWNERS, with non-openshift-org-member logins filtered out to match how the existing per-repo OWNERS files here are generated.

Verified core-services/jira-lifecycle-plugin/config.yaml already covers osac-project via an org-wide wildcard (repos: '*'), so no per-repo Jira project config is needed there.

Ran make prow-config (determinize-prow-config) locally against these new files -- zero diff, confirming they're already in canonical generated form.

One open question for reviewers: does onboarding a repo this way (hand-authored config mirroring an existing sibling) fully cover everything a brand-new repo needs, or does a repo also require webhook/GitHub App provisioning that the interactive make new-repo (repo-init) tool would normally set up and that this PR doesn't touch? osac-project/osac isn't entirely new to GitHub (it's been live for a while), but I want to confirm rather than assume this PR alone is sufficient to produce live gating.

Summary by CodeRabbit

Adds Prow configuration to onboard osac-project/osac into OpenShift CI. The configuration defines repository ownership, approval and LGTM policies, Jira validation, Tide gating, plugins, and trusted trigger applications.

The configuration mirrors the existing osac-operator setup and uses repository-specific ownership. make prow-config produced no diff after generation.

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.