Private Repositories and Fixing Embargoed CVEs
OpenShift CI supports setting up CI jobs for private repositories mainly to allow temporary non-public development on the forks of the otherwise public repositories. The CI jobs executed for these forks are not shown in the public Deck instance, and all their artifacts are not public. Access to these jobs is limited to engineers who need it.
Unfortunately, such access cannot be granted to developers of other private repositories. Therefore, OpenShift CI only allows setting up public CI jobs for private repositories – the logs and artifacts executed for such private repository will be public. Only set up such jobs when you are absolutely sure your jobs would not leak any sensitive information.
To allow the CI jobs to access a private repo, drop a following file to the directory in
openshift/release holding the
ci-operator configuration for your repository (usually
openshift-priv organization holds private forks of selected repositories. The purpose of these forks is to allow
temporary non-public development. Their presence, content, settings, and all CI configuration are managed automatically.
Automated tools manage all CI configuration for repositories in openshift-priv organization. Humans should not change any CI configuration related to these repositories. All manual changes to this configuration will be overwritten.
The set of repositories that are managed automatically in
openshift-priv is dynamic and consists of the following two subsets:
- Repositories with existing CI configuration promoting
ocp/4.Xnamespace (same criteria like for enrollment into the centralized release branch management)
- Repositories explicitly listed in the allowlist
When a repository is identified to be included in
openshift-priv by having the appropriate promoting configuration or by
being present in the allowlist, the following jobs and tools maintain the existence, repository settings, repository
content, and all necessary CI configuration of the fork in
- The periodic-auto-private-org-peribolos-sync job runs the private-org-peribolos-sync tool to maintain the GitHub settings for the fork. These settings are asynchronously consumed by the periodic-org-sync job running the peribolos tool to create the fork on GitHub and maintain its settings
job runs the private-org-sync tool to
gitcontent of the fork with the source repository.
- The periodic-prow-auto-config-brancher runs
ci-operator-config-mirrortool to create and maintain the CI configuration for the fork (
ci-operatorconfiguration files). The same job then generates the CI jobs from the
ci-operatorfiles. This has a caveat of not carrying over handcrafted (non-generated) jobs and also manual changes to the generated jobs.
- The periodic-prow-auto-config-brancher also runs the private-prow-configs-mirror tool to mirror the repository-specific Prow configuration, like merging criteria, plugin enablement, etc.