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
The documentation covers a process for releasing FBC bundles with single
step. A couple of new files and modification of existing are now
described in the doc that are required for the ones step.
JIRA: ISV-5508
Signed-off-by: Ales Raszka <araszka@redhat.com>
1. Make a pull request with a new operator bundle or catalog changes
13
-
1. Verify tests and fix problems, if possible
14
-
1. Ask for help in the PR in case of problems
12
+
- Add template to catalog mapping
13
+
4. Configure the `release-config.yaml` file if you want to automatically release the operator to the OCP catalogs. [More info](./fcb_autorelease.md#release-configyaml)
14
+
5. Make a pull request with a new operator bundle or catalog changes
By the nature of the File-Based Catalog (FBC) mode, the release of operator is made of two steps.
3
+
* The first step builds, test and release bundle image
4
+
* The second step adds a bundle to OCP catalog and releases it
5
+
6
+
The second step can be now automated and user is no longer required to manually create a
7
+
second PR with catalog changes. The release pipeline will take care of it.
8
+
9
+
The process will require an additional configuration in the `release-config.yaml` file.
10
+
Once a PR with new bundle and `release-config.yaml` is merged, the release pipeline will
11
+
open a new PR with catalog changes.
12
+
13
+
Example of such PR can be found [here](https://github.com/Allda/community-operators-pipeline-preprod/pull/20).
14
+
The second PR is linked with it original PR and looks like [this](https://github.com/Allda/community-operators-pipeline-preprod/pull/25):
15
+
16
+
17
+
18
+
## release-config.yaml
19
+
20
+
If you want your operators to be automatically released to the OCP catalogs in the FBC mode,
21
+
you will need to configure the `release-config.yaml` file. The file should be placed
22
+
into the bundle version directory, e.g. `operators/aqua/0.0.2/release-config.yaml`.
23
+
24
+
```
25
+
tree operators/aqua
26
+
.
27
+
├── 0.0.2
28
+
│ ├── release-config.yaml # This is the file
29
+
│ ├── manifests
30
+
│ └── metadata
31
+
├── catalog-templates
32
+
├── ci.yaml
33
+
└── Makefile
34
+
```
35
+
Its content determines where exactly the bundle will be released in terms of
36
+
the OCP version and the place in the update graph.
37
+
38
+
### Example
39
+
40
+
```yaml
41
+
---
42
+
catalog_templates:
43
+
- template_name: basic.yaml
44
+
channels: [my-channel]
45
+
replaces: aqua.0.0.1
46
+
- template_name: semver.yaml
47
+
channels: [Fast, Stable]
48
+
```
49
+
The example above shows a release configuration where operator bundle is going to be
50
+
released to the `my-channel` channel in the `basic.yaml` catalog template and to the
51
+
`Fast`and `Stable` channels in the `semver.yaml` catalog template.
52
+
53
+
The `replaces` field is optional and it specifies the bundle that the new bundle
54
+
replaces in the update graph.
55
+
56
+
### File structure
57
+
The schema of the file is available here: [release-config.yaml schema](https://github.com/redhat-openshift-ecosystem/operator-pipelines/blob/main/operator-pipeline-images/operatorcert/schemas/release-config-schema.json).
58
+
The schema is validated automatically in the pipeline and the PR will fail with explanations if the file is not valid.
59
+
60
+
Here is a summary of the file structure:
61
+
62
+
* The top-level key is `catalog_templates` which is a list of objects.
63
+
* Each object has the following keys:
64
+
* `template_name` - the name of the catalog template file in the `catalog-templates` directory.
65
+
* `channels` - a list of channels where the bundle should be released.
66
+
* In case of using `SemVer` a user can pick from allowed values: `Fast`, `Stable` and `Candidate`.
67
+
* `replaces` - the bundle that the new bundle replaces in the update graph. (**Optional**, only for the basic templates)
68
+
* `skips` - a list of bundles that should be skipped in the update graph. (**Optional**, only for the basic templates)
69
+
* `skipRange` - a range of bundles that should be skipped in the update graph. (**Optional**, only for the basic templates)
Copy file name to clipboardExpand all lines: docs/users/operator-ci-yaml.md
+19-2Lines changed: 19 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -45,12 +45,29 @@ The `fbc.version_promotion_strategy` option defines the strategy for promoting t
45
45
-`always` - the operator will be promoted to the next OCP version automatically
46
46
-`review-needed` - the operator will be promoted to the next OCP version automatically, but the PR will be created and the reviewers will be asked to review the changes
47
47
48
+
### `fbc.catalog_mapping`
49
+
The mapping serves as a link between catalog templates within the `./catalog-templates` directory and catalogs within the `./catalogs` directory.
50
+
51
+
For more details and structure visit the [FBC workflow page](./fbc_workflow.md#fcb-template-mapping).
52
+
48
53
### Example
49
54
```yaml
50
55
---
51
56
fbc:
52
-
enabled: true
53
-
version_promotion_strategy: never
57
+
enabled: true
58
+
version_promotion_strategy: never
59
+
catalog_mapping:
60
+
- template_name: my-custom-semver-template.yaml # The name of the file inside ./catalog-templates directory
61
+
catalogs_names: # a list of catalogs within the /catalogs directory
62
+
- "v4.15"
63
+
- "v4.16"
64
+
- "v4.17"
65
+
type: olm.semver
66
+
- template_name: my-custom-basic-template.yaml # The name of the file inside catalog-templates directory
Copy file name to clipboardExpand all lines: docs/users/static_checks.md
+13-9Lines changed: 13 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -52,15 +52,15 @@ The test is based on `operator-sdk bundle validate` command with `name=operatorh
52
52
The test is based on `operator-sdk bundle validate` command with `suite=operatorframework` test suite [(link)](https://sdk.operatorframework.io/docs/cli/operator-sdk_bundle_validate/#operator-sdk-bundle-validate).
53
53
54
54
#### check_required_fields
55
-
| Field name | Validation | Description |
56
-
|------------|------------|------|
57
-
|`spec.displayName`|`.{3,50}`| A string with 3 - 50 characters |
58
-
|`spec.description`|`.{20,}`| A bundle description with at least 20 characters |
59
-
|`spec.icon`|`media`| A valid base64 content with a supported media type (`{"base64data": <b64 content>, "mediatype": enum["image/png", "image/jpeg", "image/gif", "image/svg+xml"]}`) |
60
-
|`spec.version`|`SemVer`| Valid semantic version |
61
-
|`spec.maintainers`|| At least 1 maintainer contacts. Example: `{"name": "User 123", "email": "user@redhat.com"}`|
62
-
|`spec.provider.name`|`.{3,}`| A string with at least 3 characters |
63
-
|`spec.links`|| At least 1 link. Example: `{"name": "Documentation", "url": "https://redhat.com"}`|
|`spec.displayName`|`.{3,50}`| A string with 3 - 50 characters|
58
+
|`spec.description`|`.{20,}`| A bundle description with at least 20 characters|
59
+
|`spec.icon`|`media`| A valid base64 content with a supported media type (`{"base64data": <b64 content>, "mediatype": enum["image/png", "image/jpeg", "image/gif", "image/svg+xml"]}`) |
60
+
|`spec.version`|`SemVer`| Valid semantic version|
61
+
|`spec.maintainers`|| At least 1 maintainer contacts. Example: `{"name": "User 123", "email": "user@redhat.com"}`|
62
+
|`spec.provider.name`|`.{3,}`| A string with at least 3 characters|
63
+
|`spec.links`|| At least 1 link. Example: `{"name": "Documentation", "url": "https://redhat.com"}`|
64
64
65
65
#### check_dangling_bundles
66
66
The test prevents from releasing an operator and keeping any previous bundle dangling.
@@ -133,6 +133,10 @@ This check will ensure that all bundle images in the file based catalog for give
133
133
operator catalog(s) use allowed image registry. Allowed registries are configured
134
134
in `(repo_root)/config.yaml` under the key `allowed_bundle_registries`.
135
135
136
+
#### check_schema_bundle_release_config
137
+
The test validates the `release-config.yaml` file against the schema. The schema
138
+
the file including the schema is described [here](./fcb_autorelease.md#release-configyaml)
0 commit comments