Skip to content

openshift-knative/serving

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Openshift Knative Serving

This repository holds Openshift's fork of knative/serving with additions and fixes needed only for the OpenShift side of things.

How this repository works ?

The default branch holds up-to-date specific openshift files that are necessary for CI setups and maintaining it. This includes:

  • Scripts to create a new release branch from upstream
  • CI setup files
    • operator configuration (for Openshift's CI setup)
    • tests scripts
  • Operator's base configurations

Each release branch holds the upstream code for that release and our openshift's specific files.

CI Setup

For the CI setup, three repositories are of importance:

All of the following is based on OpenShift’s CI operator configs. General understanding of that mechanism is assumed in the following documentation.

The job manifests for the CI jobs are generated via openshift-knative/hack. The basic configuration lives in the ci-operator/config/openshift-knative/serving folder of the openshift/release repository. These files include which version to build against (OCP 4.x), which images to build (this includes all the images needed to run Knative and also all the images required for running e2e tests) and which command to execute for the CI jobs to run (more on this later).

Before we can create the ci-operator configs mentioned above, we need to make sure there are Dockerfiles for all images that we need (they’ll be referenced by the ci-operator config hence we need to create them first). The generate-dockerfiles.sh script takes care of creating all the Dockerfiles needed automatically. The files now need to be committed to the branch that CI is being setup for.

The Knative Serving release files are generated via the generate-release.sh file in the openshift-knative/serving repository.

After the file has been added to the folder as mentioned above, the job manifests itself will need to be generated as is described in the corresponding ci-operator documentation. This process is automated using openshift-knative/hack.

Once all of this is done (Dockerfiles committed, ci-operator config created and job manifests generated and pushed), the CI setup for that branch is active.

Create a new release

Refer to the release manual.

Sync upstream

Sometimes, upstream releases a micro release (e.g. v1.10.1) after downstream has already cut a minor release. To synchronize with the upstream release, we can trigger the GitHub action "Sync upstream" available at this link. Please make sure to set:

  • Use workflow from: Branch: main
  • Release Version: downstream brach (e.g. release-v1.10)

Afterward, the downstream branch release-v1.10 will synchronize with the upstream's release-1.10 branch. The GitHub action will create a pull request, similar to pull/345.

About

Kubernetes-based, scale-to-zero, request-driven compute

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages

  • Shell 87.4%
  • Makefile 8.2%
  • Dockerfile 4.4%