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>
@@ -79,6 +87,7 @@ Failures at this stage are rare. To diagnose the issue, review the pipeline logs
79
87
80
88
### <aid="detect-changes"></a>detect-changes
81
89
The pipeline may fail at this stage due to the following reasons:
90
+
82
91
1. <b>Changing Non-Operator Files:</b> If the PR attempts to modify external files outside of targeted operator, the pipeline will fail.
83
92
1. <b>Affecting Multiple Operators:</b> If the PR impacts more than one operator, it will result in a failure.
84
93
1. <b>Modifying Existing Bundles:</b> Changes to existing bundles in the PR are not allowed at this stage.
@@ -88,8 +97,8 @@ Other Failures at this stage are rare. To diagnose the issue, review the pipelin
88
97
89
98
### <aid="yaml-lint"></a>yaml-lint
90
99
91
-
**Warnings** at this step should be addressed if possible but won't result in a failure.
92
-
**Errors** at this step will need to be addressed. Often errors center around <i>unexpected whitespace</i> at the end of lines or <i>missing newlines</i> at the end of your `yaml` files.
100
+
**Warnings** at this step should be addressed if possible but won't result in a failure.
101
+
**Errors** at this step will need to be addressed. Often errors center around <i>unexpected whitespace</i> at the end of lines or <i>missing newlines</i> at the end of your `yaml` files.
Failures at this stage are rare. To diagnose the issue, review the pipeline logs linked in the PipelineRun summary within the PR. If the logs don’t clarify the problem, feel free to ask for assistance in the PR comments. Maintainers will assist in identifying and resolving the issue.
@@ -127,6 +136,7 @@ If the static tests fail, a summary will be posted as a comment on the Pull Requ
127
136
128
137
129
138
To proceed:
139
+
130
140
1. Review the comment for the detailed reasons behind the failed static tests.
131
141
1. Fix all the reported issues.
132
142
1. Commit the changes with a fix to the PR and it will Re-trigger the hosted pipeline.
@@ -158,6 +168,7 @@ Failures at this stage are rare. To diagnose the issue, review the pipeline logs
158
168
Failures at this stage are rare and often due to transient issues. Start by reviewing the pipeline logs linked in the PipelineRun summary within the PR.
159
169
160
170
As an initial step, re-trigger the pipeline by adding the appropriate command in the PR comment:
171
+
161
172
1. `/pipeline restart operator-hosted-pipeline` for the hosted pipeline.
162
173
1. `/pipeline restart operator-release-pipeline` for the release pipeline.
163
174
@@ -173,12 +184,13 @@ Failures at this stage are rare. To diagnose the issue, review the pipeline logs
173
184
Failures at this stage are rare. To diagnose the issue, review the pipeline logs linked in the PipelineRun summary within the PR. If the logs don’t clarify the problem, feel free to ask for assistance in the PR comments. Maintainers will assist in identifying and resolving the issue.
At this step, the pipeline will primarily fail if the [dynamic tests](../users/dynamic_checks.md) do not pass completely. A link to the test artifacts will be posted as a comment on the PR, as shown below.
187
+
At this step, the pipeline will primarily fail if the [dynamic tests](../users/dynamic_checks.md) do not pass completely. A link to the test artifacts will be posted as a comment on the PR, as shown below.
177
188
178
189
179
190
180
191
Please review this link, as it will provide detailed error information.
181
192
Failures at this stage are uncommon. To diagnose the issue:
193
+
182
194
1. Review the pipeline logs linked in the PipelineRun summary within the PR.
183
195
1. Examine the test artifacts for detailed error information.
184
196
@@ -191,7 +203,7 @@ Failures at this stage are rare. To diagnose the issue, review the pipeline logs
191
203
Failures at this stage are rare. To diagnose the issue, review the pipeline logs linked in the PipelineRun summary within the PR. If the logs don’t clarify the problem, feel free to ask for assistance in the PR comments. Maintainers will assist in identifying and resolving the issue.
192
204
193
205
### <aid="merge-pr"></a>merge-pr
194
-
If operator hosted pipeline fails at this task with the error message: `Pull request Auto merge is not allowed for this repository (enablePullRequestAutoMerge)` then re-trigger the pipeline by running command `/pipeline restart operator-hosted-pipeline`.
206
+
If operator hosted pipeline fails at this task with the error message: `Pull request Auto merge is not allowed for this repository (enablePullRequestAutoMerge)` then re-trigger the pipeline by running command `/pipeline restart operator-hosted-pipeline`.
195
207
196
208
Another Failures at this stage are rare. To diagnose the issue, review the pipeline logs linked in the PipelineRun summary within the PR. If the logs don’t clarify the problem, feel free to ask for assistance in the PR comments. Maintainers will assist in identifying and resolving the issue.
197
209
@@ -223,4 +235,3 @@ Failures at this stage are rare. To diagnose the issue, review the pipeline logs
Failures at this stage are rare. To diagnose the issue, review the pipeline logs linked in the PipelineRun summary within the PR. If the logs don’t clarify the problem, feel free to ask for assistance in the PR comments. Maintainers will assist in identifying and resolving the issue.
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
+
4
+
* The first step builds, test and release bundle image
5
+
* The second step adds a bundle to OCP catalog and releases it
6
+
7
+
The second step can be now automated and user is no longer required to manually create a
8
+
second PR with catalog changes. The release pipeline will take care of it.
9
+
10
+
The process will require an additional configuration in the `release-config.yaml` file.
11
+
Once a PR with new bundle and `release-config.yaml` is merged, the release pipeline will
12
+
open a new PR with catalog changes.
13
+
14
+
Example of such PR can be found [here](https://github.com/Allda/community-operators-pipeline-preprod/pull/20).
15
+
The second PR is linked with it original PR and looks like [this](https://github.com/Allda/community-operators-pipeline-preprod/pull/25):
16
+
17
+
18
+
19
+
## release-config.yaml
20
+
21
+
If you want your operators to be automatically released to the OCP catalogs in the FBC mode,
22
+
you will need to configure the `release-config.yaml` file. The file should be placed
23
+
into the bundle version directory, e.g. `operators/aqua/0.0.2/release-config.yaml`.
24
+
25
+
```
26
+
tree operators/aqua
27
+
.
28
+
├── 0.0.2
29
+
│ ├── release-config.yaml # This is the file
30
+
│ ├── manifests
31
+
│ └── metadata
32
+
├── catalog-templates
33
+
├── ci.yaml
34
+
└── Makefile
35
+
```
36
+
Its content determines where exactly the bundle will be released in terms of
37
+
the OCP version and the place in the update graph.
38
+
39
+
### Example
40
+
41
+
```yaml
42
+
---
43
+
catalog_templates:
44
+
- template_name: basic.yaml
45
+
channels: [my-channel]
46
+
replaces: aqua.0.0.1
47
+
- template_name: semver.yaml
48
+
channels: [Fast, Stable]
49
+
```
50
+
The example above shows a release configuration where operator bundle is going to be
51
+
released to the `my-channel` channel in the `basic.yaml` catalog template and to the
52
+
`Fast`and `Stable` channels in the `semver.yaml` catalog template.
53
+
54
+
The `replaces` field is optional and it specifies the bundle that the new bundle
55
+
replaces in the update graph.
56
+
57
+
### File structure
58
+
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).
59
+
The schema is validated automatically in the pipeline and the PR will fail with explanations if the file is not valid.
60
+
61
+
Here is a summary of the file structure:
62
+
63
+
* The top-level key is `catalog_templates` which is a list of objects.
64
+
* Each object has the following keys:
65
+
* `template_name` - the name of the catalog template file in the `catalog-templates` directory.
66
+
* `channels` - a list of channels where the bundle should be released.
67
+
* In case of using `SemVer` a user can pick from allowed values: `Fast`, `Stable` and `Candidate`.
68
+
* `replaces` - the bundle that the new bundle replaces in the update graph. (**Optional**, only for the basic templates)
69
+
* `skips` - a list of bundles that should be skipped in the update graph. (**Optional**, only for the basic templates)
70
+
* `skipRange` - a range of bundles that should be skipped in the update graph. (**Optional**, only for the basic templates)
0 commit comments