You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/downstream-ci.md
+23-22Lines changed: 23 additions & 22 deletions
Original file line number
Diff line number
Diff line change
@@ -4,62 +4,63 @@ The CI configuration for each release branch can be found [here](https://github.
4
4
From `4.11` (`master` as of this writing) we've updated the configuration to able to influence CI on a PR basis. An overview of the `ci-operator` (the system used for ci)
5
5
can be found [here](https://docs.ci.openshift.org/docs/architecture/ci-operator/).
6
6
7
-
###Structure
7
+
## Structure
8
8
9
-
*`.ci-operator.yaml` defines the `build_root_image`. To be ART compliant, the image should come from the [ocp-build-data](https://github.com/openshift/ocp-build-data/) repo
10
-
*[openshift-operator-framework-olm-master.yaml](https://github.com/openshift/release/blob/master/ci-operator/config/openshift/operator-framework-olm/openshift-operator-framework-olm-master.yaml) defines the images that are used by ci, produced by ci, and the ci jobs the get executed.
11
-
*`base.Dockerfile` defines the image used by ci to execute the ci jobs
9
+
-`.ci-operator.yaml` defines the `build_root_image`. To be ART compliant, the image should come from the [ocp-build-data](https://github.com/openshift/ocp-build-data/) repo
10
+
-[openshift-operator-framework-olm-master.yaml](https://github.com/openshift/release/blob/master/ci-operator/config/openshift/operator-framework-olm/openshift-operator-framework-olm-master.yaml) defines the images that are used by ci, produced by ci, and the ci jobs the get executed.
11
+
-`base.Dockerfile` defines the image used by ci to execute the ci jobs
12
12
13
13
From [openshift-operator-framework-olm-master.yaml](https://github.com/openshift/release/blob/master/ci-operator/config/openshift/operator-framework-olm/openshift-operator-framework-olm-master.yaml), we see under the `images` stanza the `ci-image` definition.
14
14
It goes from `src` (the `build_root_image`) to `ci-image` by building `base.Dockerfile` with `src` as the base image.
15
15
16
-
```
16
+
```yaml
17
17
- dockerfile_path: base.Dockerfile
18
18
from: src
19
19
to: ci-image
20
20
```
21
21
22
22
The image is excluded from promotion, to never be posted up anywhere:
23
23
24
-
```
24
+
```yaml
25
25
promotion:
26
26
excluded_images:
27
27
- ci-image
28
28
```
29
29
30
30
and each `test` references `ci-image` as the image to be used to the test, e.g.:
31
31
32
-
```
32
+
```yaml
33
33
tests:
34
34
- as: verify
35
35
commands: make verify
36
36
container:
37
37
from: ci-image
38
38
```
39
39
40
-
###Updating go versions
40
+
## Updating go versions
41
41
42
-
All we need to do is update the `build_root_image` referenced in `.ci-operator.yaml` and we may also need to update the `base_images` in [openshift-operator-framework-olm-master.yaml](https://github.com/openshift/release/blob/master/ci-operator/config/openshift/operator-framework-olm/openshift-operator-framework-olm-master.yaml).
42
+
All we need to do is update the `build_root_image` referenced in `.ci-operator.yaml` and we may also need to update the `base_images` in [openshift-operator-framework-olm-master.yaml](https://github.com/openshift/release/blob/master/ci-operator/config/openshift/operator-framework-olm/openshift-operator-framework-olm-master.yaml).
43
43
44
44
**NOTE**: I believe there is some automation that updates the base images, though I don't know. I'll leave this as a questions to the reviewer, and if no one knows, I'll go after it.
45
45
46
-
###Downstream sync
46
+
## Downstream sync
47
47
48
48
The complete information about the downstreaming process can be found [here](https://docs.google.com/document/d/139yXeOqAJbV1ndC7Q4NbaOtzbSdNpcuJan0iemORd3g/edit).
49
49
50
50
TL;DR;
51
51
52
52
We sync three upstream repositories ([api](https://github.com/operator-framework/api), [registry](https://github.com/operator-framework/operator-registry), [olm](https://github.com/operator-framework/operator-lifecycle-manager)) to the downstream [olm mono-repo](https://github.com/openshift/operator-framework-olm). Commits from the upstream repositories are cherry-picked to the appropriate `staging` directory in the downstream repository. Because this is a monorepo in the `Openshift` GitHub organization, two things need to be remembered:
53
-
- we don't pull in upstream `vendor` folder changes
54
-
- we don't pull in changes to `OWNERS` files
55
-
- after each cherry-pick we execute: `make vendor` and `make manifests` to ensure a) the downstream dependencies are updated b) to ensure any manifest changes are picked up downstream
While manual changes to the `staging` directory should be avoided, there could be instances where there drift between the downstream `staging` directory and the corresponding upstream repository. This can happen due to applying commits out-of-order, e.g. due to feature freeze, etc.
54
+
- we don't pull in upstream `vendor` folder changes
55
+
- we don't pull in changes to `OWNERS` files
56
+
- after each cherry-pick we execute: `make vendor`and `make manifests` to ensure a) the downstream dependencies are updated b) to ensure any manifest changes are picked up downstream
While manual changes to the `staging` directory should be avoided, there could be instances where there drift between the downstream `staging` directory and the corresponding upstream repository. This can happen due to applying commits out-of-order, e.g. due to feature freeze, etc.
59
60
60
-
Therefore, after a sync, it is important to manually verify the diff of `staging` and the upstream. Please note, though, that some downstream changes are downstream only. These are, however, few and far between and there are comments to indicate that a block of code is downstream only.
61
+
Therefore, after a sync, it is important to manually verify the diff of `staging` and the upstream. Please note, though, that some downstream changes are downstream only. These are, however, few and far between and there are comments to indicate that a block of code is downstream only.
61
62
62
-
The downstream sync process is facilitated by two scripts: `scripts/sync_get_candidates.sh` and `scripts/sync_pop_candidate.sh`, which compare the upstream remote with the appropriate `staging` directory and gets a stack of commits to sync, and cherry-pick those commits in reverse order. What does this look like in practice:
63
+
The downstream sync process is facilitated by two scripts: `scripts/sync_get_candidates.sh`and `scripts/sync_pop_candidate.sh`, which compare the upstream remote with the appropriate `staging` directory and gets a stack of commits to sync, and cherry-pick those commits in reverse order. What does this look like in practice:
# staging/operator-lifecycle-manager/go.mod and go.sum
122
123
$ cd staging/operator-lifecycle-manager
123
124
$ go mod tidy
@@ -131,4 +132,4 @@ $ sync_pop_candidate.sh operator-lifecycle-manager -a
131
132
132
133
#### Running console test locally
133
134
134
-
The [console](https://github.com/openshift/console) repository contains all instructions you need to execute the console tests locally. The olm console tests can be found [here](https://github.com/openshift/console/tree/master/frontend/packages/operator-lifecycle-manager)
135
+
The [console](https://github.com/openshift/console) repository contains all instructions you need to execute the console tests locally. The olm console tests can be found [here](https://github.com/openshift/console/tree/master/frontend/packages/operator-lifecycle-manager)
We can use CRC as an Openshift-like environment within which to test downstream OLM. [CRC](https://developers.redhat.com/products/codeready-containers/overview)
3
+
We can use CRC as an Openshift-like environment within which to test downstream OLM. [CRC](https://developers.redhat.com/products/codeready-containers/overview)
4
4
is a tool for deploying a local Openshift cluster on your laptop.
4. Execute e2e tests as you normally would, e.g., `make e2e/olm`
12
12
13
-
####Gosh darn it, how does it work?
13
+
## Gosh darn it, how does it work?
14
14
15
15
`./scripts/crc-start.sh` is used to provision a crc cluster. `./scripts/crc-deploy.sh` pushes the `olm:test` and `opm:test` to
16
16
`image-registry.openshift-image-registry.svc:5000/openshift/olm:test` and `image-registry.openshift-image-registry.svc:5000/openshift/opm:test`
17
17
images to the crc image registry under the global project `openshift` (to be independent from the olm namespace). It also generates an image stream
18
-
from these images. Finally, using the istag for the image. It also generates the olm manifests by applying generated helm values file (`values-crc-e2e.yaml`)
18
+
from these images. Finally, using the istag for the image. It also generates the olm manifests by applying generated helm values file (`values-crc-e2e.yaml`)
19
19
and other generated yaml patches (`scripts/*.crc.e2e.patch.yaml`) to make sure the manifests point to the newly pushed images. The generated manifests are
20
20
then applied to the cluster using `kubectl replace` in priority order (lexical sort).
21
21
22
-
####Make targets
22
+
## Make targets
23
23
24
24
1.`make crc-start`: provision a crc cluster, if necessary
25
25
1.`FORCE_CLEAN=1 make crc-start`: nuke any current installation including cache and current cluster instance
@@ -29,7 +29,7 @@ then applied to the cluster using `kubectl replace` in priority order (lexical s
29
29
2.`SKIP_WAIT_READY=1 make crc-deploy`: skip waiting for olm deployments to be available at the end
30
30
4.`make crc`: the same as `make crc-start crc-build crc-deploy`
31
31
32
-
####Manipulating Resources
32
+
## Manipulating Resources
33
33
34
34
If new resources are introduced that require being updated for local deployment (e.g. updating the pod spec image) follow
35
-
the pattern used in `scripts/crc-deploy.sh:make_manifest_patches`
35
+
the pattern used in `scripts/crc-deploy.sh:make_manifest_patches`.
0 commit comments