# openshift/origin: what the openshift-tests binary actually is now

> Origin stopped being the place where OpenShift's hyperkube binaries live. What remains on main is the conformance and e2e test suite, and this article covers how it is built, run and vendored.

**openshift/origin** — Conformance test suite for OpenShift

- Repository: https://github.com/openshift/origin
- Website: http://www.openshift.org
- Stars: 8,691 · Forks: 4,804
- Language: Go
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/openshift-origin

## What openshift/origin is now, and who it is for

The README opens with a correction that most people arriving at this repository need to read twice: this repo was previously the core Kubernetes tracking repo for OKD, and where OpenShift's hyperkube and openshift-test binaries were maintained. As of July 2020, the purpose and maintenance strategy of the repo varies by branch. That sentence is the whole framing. If you came here looking for the thing that builds a Kubernetes distribution, you are on the wrong repository for anything 4.6 and newer.

On main and the release-x.x branches for 4.6 and above, the repository no longer includes the code required to produce hyperkube binaries. It is limited to maintaining the openshift-tests binary. Responsibility for hyperkube moved to openshift/kubernetes. Release-4.5, release-4.4 and release-4.3 still maintain hyperkube in origin, and carries and backports for those branches are still submitted here; openshift/kubernetes is not involved except for rebases.

So the audience is narrow and specific. You are a platform or test engineer working against an OpenShift cluster who wants to run the upstream conformance and extended e2e suites. Or you maintain the exclusion rules that decide which kube e2e tests are known to be incompatible with a given OpenShift configuration. The repository is Go, Apache-2.0, and the last push was on 2026-09-19.

## How the test binary and the vendoring split work

All e2e tests are compiled into a single openshift-tests binary. That is the central mechanism: the suites are not shipped as a service or a set of per-test packages you invoke individually, they are linked into one executable, and the Makefile target openshift-tests sets GO_BUILD_PACKAGES to ./cmd/openshift-tests before calling the generic build target. The README states the design constraint on the tests themselves: two e2e tests should not overlap more than 10% of function, and they are not intended to test error conditions in detail.

The repository vendors k8s.io/kubernetes and some of its staging repos from the openshift/kubernetes fork rather than upstream. Upstream staging repos are used where possible, but the README notes that some tests depend on functionality that is only present in the fork. Branch names are correlated across the two repositories, so master in openshift/kubernetes is vendored into main in origin. The README also flags that this arrangement is intended to be temporary, with a stated plan to switch to origin-specific branches such as origin-4.6-kubernetes-1.19.2.

Test exclusion is the other moving part, and it changed shape. Exclusion is handled through environmental selector based filtering rather than test annotations, so tests are filtered or skipped based on cluster environment and configuration. The rules are deliberately split in two: kube e2e selectors live in openshift/kubernetes under openshift-hack/cmd/k8s-tests-ext, and OpenShift e2e selectors live in this repository under pkg/test/extensions. The stated reason for the split is that PRs proposed to openshift/kubernetes can be validated against the set of kube e2e tests known to be compatible with OpenShift.

## Building openshift-tests and running a first suite

There is no install step in the usual sense. The README gives one build instruction for the test binary: run make. The Makefile's default target is all, which depends on build, and the repository uses the openshift/build-machinery-go makefiles vendored under vendor/github.com/openshift/build-machinery-go/make/. A Go toolchain matching the go directive in go.mod, which is go 1.26.0, is the prerequisite the module file implies.

```bash
make
```

After that completes you have the openshift-tests binary. The README does not spell out the invocation flags for running a suite; it points to test/extended/README for how to run a specific test or an entire suite. Treat that file as the real entry point rather than the top-level README, because the top-level document stops at the build step.

The Makefile also exposes a narrower target for people who only care about this binary:

```bash
make openshift-tests
```

That target sets GO_BUILD_PACKAGES to ./cmd/openshift-tests and delegates to build. If you are changing test code and want the fastest loop, this is the one to use. For repository checks there is make verify, which runs verify-origin (the JSON format, generated-code and TLS ownership scripts) plus verify-apm.

## Vendoring a change from openshift/kubernetes without breaking your tree

If a change merges to an openshift/kubernetes branch and needs to land here, the README directs you to hack/update-kube-vendor.sh, which updates the go module configuration for all dependencies sourced from openshift/kubernetes on that branch. It takes a branch name or a SHA:

```bash
hack/update-kube-vendor.sh <openshift/kubernetes branch name or SHA>
```

The script also supports a fake bump so you can validate an as-yet-unmerged change in openshift/kubernetes by passing the name of a fork repository as a second argument:

```bash
hack/update-kube-vendor.sh <branch name or SHA> github.com/myname/kubernetes
```

After the script runs, the vendoring changes still have to be committed and proposed. The README documents one failure mode explicitly: the script can return a 410 Gone error when the Go checksum server does not yet know about the target SHA, with a server response of not found. The documented workaround is to disable the checksum database for that update:

```bash
GOSUMDB=off hack/update-kube-vendor.sh <branch name or SHA>
```

That is a real trade-off, not a footnote. Turning off GOSUMDB for a vendoring bump means the checksum verification that would normally catch a mismatched module is skipped for the duration of the command, so the value you get back is only as trustworthy as the source you pointed the script at.

## Where origin is the wrong tool

The clearest failure case is anyone who needs hyperkube. On main and on release-x.x for 4.6 and above, the code required to produce those binaries is gone. Backports and carries against upstream are proposed to openshift/kubernetes, and if a change merged there needs to land in origin, the follow-up is a PR here that bumps the vendoring. Working against origin for that purpose means you are editing a mirror rather than the source, and your change will be overwritten by the next bump.

The second case is release history. The newest listed release is v3.11.0 from 2018-10-11, with v3.10.0 from 2018-08-03 before it. Anyone who needs a versioned artifact to pin in a pipeline will not find one that corresponds to the current main branch. The repository is not archived and the last push was on 2026-09-19, so the code moves, but the release tags do not track it.

The third case is anyone treating this as a general-purpose test framework. The README scopes e2e tests to verifying long flows as a user would see them, explicitly not detailed error-condition testing, and caps overlap between two e2e tests at 10% of function. If you want unit-level or fault-injection coverage, this suite is not designed for it and the exclusion selectors will not help you.

Finally, the exclusion rules being split across two repositories is a coordination cost. Updating kube e2e exclusions means a PR to openshift/kubernetes; updating OpenShift e2e exclusions means editing pkg/test/extensions here. There is no single place to see the full set of skipped tests.

## Compared with running upstream Kubernetes e2e directly

The obvious alternative is to run the upstream Kubernetes e2e suite against the cluster without going through origin at all. The difference is not the tests themselves, since origin vendors k8s.io/kubernetes and its staging repos from the openshift/kubernetes fork. The difference is the filtering layer and the carries.

Running upstream directly leaves you without the environmental selector based exclusions that origin maintains, so tests known to be incompatible with a specific OpenShift configuration will run and fail, and you are the one who has to work out which failures are real. It also leaves you without the fork-only functionality that the README says some tests depend on. In exchange, you avoid the vendoring coupling: origin's main branch is tied to whatever openshift/kubernetes branch it is currently vendoring, and the README says that coupling is intended to be temporary, with a move planned toward origin-specific branches. Until that happens, a change in the fork can force a vendoring bump here.

If your goal is to validate OpenShift itself, the exclusion rules are the product, and running upstream raw discards them. If your goal is to validate a Kubernetes distribution that is not OpenShift, origin's selectors are tuned for OpenShift configurations and add nothing.

## Licence and the cost of keeping this current

The repository is Apache-2.0, and the README carries the licence badge linking to the Apache 2.0 text. For most users that is the end of the question: Apache-2.0 permits use, modification and redistribution with the usual notice and patent terms. The thing to check is not origin's own licence but the licences of what it vendors, since the tree pulls in k8s.io/kubernetes and staging repos from the openshift/kubernetes fork, plus a large dependency set visible in go.mod spanning cloud SDKs from Google, Azure, AWS and IBM. Those carry their own terms. This is not legal advice; if you redistribute a built artifact, read the vendored licences.

The maintenance cost is dominated by the vendoring workflow rather than by test authoring. Every change that needs to come from openshift/kubernetes requires a bump PR here, and the README's stated intent is to reduce that scope by moving to origin-specific branches. Until that switch happens, expect the hack/update-kube-vendor.sh loop, including the GOSUMDB=off workaround when the checksum server has not caught up. Upgrading means picking the branch that matches your OpenShift version, because the vendoring rules differ above and below 4.6, and checking whether your exclusion rules belong in openshift/kubernetes or in pkg/test/extensions.

## Conclusion

Adopt openshift/origin if you run an OpenShift cluster and need the upstream conformance and e2e suites compiled into a single openshift-tests binary, or if you maintain test exclusion selectors for kube e2e tests. Do not adopt it expecting a hyperkube build, a server, or a stable tagged release: main carries none of those, and the newest tag is v3.11.0 from 2018-10-11. Before anything else, verify which branch matches your OpenShift version, because the vendoring rules differ between 4.6 and above and release-4.5 and below, and confirm that your test exclusion rules live in the right repository: kube e2e selectors in openshift/kubernetes, OpenShift e2e selectors in pkg/test/extensions here.

## FAQ

### What is openshift/origin used for?

It maintains the openshift-tests binary, into which all e2e tests are compiled, and it holds the environmental selector rules that exclude OpenShift e2e tests known to be incompatible with a given cluster configuration. On branches for 4.6 and above it no longer produces hyperkube binaries.

### How do I build openshift-tests from openshift/origin?

The README says to run make, and the Makefile also has a narrower openshift-tests target that sets GO_BUILD_PACKAGES to ./cmd/openshift-tests. The go.mod file declares go 1.26.0, so a matching Go toolchain is needed.

### Where are the test exclusion rules kept?

They are split. Kube e2e rules live in openshift/kubernetes under openshift-hack/cmd/k8s-tests-ext, and OpenShift e2e rules live in this repository under pkg/test/extensions, in environment_selectors.go and disabled_tests.go.

### Why does hack/update-kube-vendor.sh return a 410 Gone error?

The README attributes it to the golang checksum server not yet knowing about the target SHA. The documented workaround is to run the script with GOSUMDB=off.

### Does openshift/origin still build hyperkube?

Not on main or the release-x.x branches for 4.6 and above; that responsibility moved to openshift/kubernetes. Release-4.5, release-4.4 and release-4.3 still maintain hyperkube in origin.

## Sources

- [License: Apache-2.0](https://github.com/openshift/origin/blob/main/LICENSE)
- [openshift/origin on GitHub](https://github.com/openshift/origin)
- [Project website](http://www.openshift.org)
- [README](https://github.com/openshift/origin/blob/main/README.md)
- [Releases](https://github.com/openshift/origin/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openshift-origin