gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: config:
processors:
cumulativetodelta:
include: # <1>
match_type: strict # <2>
metrics: # <3>
- <metric_1_name>
- <metric_2_name>
exclude: # <4>
match_type: regexp
metrics:
- "<regular_expression_for_metric_names>"
# ...
----
<1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
<2> Defines a value provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
<3> Lists the metric names, which are exact matches or matches for regular expressions, of the metrics to be converted to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
<4> Optional: Configures which metrics to exclude. When omitted, no metrics are excluded from conversion to delta metrics.
Revised: <2> Optional: Configures which metrics to include. If omitted, the processor converts all metrics, except those listed in the `exclude` field, to delta metrics.
Original: config:
processors:
cumulativetodelta:
include: # <1>
match_type: strict # <2>
metrics: # <3>
- <metric_1_name>
- <metric_2_name>
exclude: # <4>
match_type: regexp
metrics:
- "<regular_expression_for_metric_names>"
# ...
----
<1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
<2> Defines a value provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
<3> Lists the metric names, which are exact matches or matches for regular expressions, of the metrics to be converted to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
<4> Optional: Configures which metrics to exclude. When omitted, no metrics are excluded from conversion to delta metrics.
Revised: <4> Lists the metric names, which are exact matches or regular expression matches for metrics to convert to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
Original: config:
processors:
cumulativetodelta:
include: # <1>
match_type: strict # <2>
metrics: # <3>
- <metric_1_name>
- <metric_2_name>
exclude: # <4>
match_type: regexp
metrics:
- "<regular_expression_for_metric_names>"
# ...
----
<1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
<2> Defines a value provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
<3> Lists the metric names, which are exact matches or matches for regular expressions, of the metrics to be converted to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
<4> Optional: Configures which metrics to exclude. When omitted, no metrics are excluded from conversion to delta metrics.
Revised: <5> Optional: Configures which metrics to exclude. If omitted, the processor does not excluded any metrics from conversion to delta metrics.
Original: config:
processors:
cumulativetodelta:
include: # <1>
match_type: strict # <2>
metrics: # <3>
- <metric_1_name>
- <metric_2_name>
exclude: # <4>
match_type: regexp
metrics:
- "<regular_expression_for_metric_names>"
# ...
----
<1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
<2> Defines a value provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
<3> Lists the metric names, which are exact matches or matches for regular expressions, of the metrics to be converted to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
<4> Optional: Configures which metrics to exclude. When omitted, no metrics are excluded from conversion to delta metrics.
Revised: <1> This processor requires a stateful Collector deployment. You can deploy the processor as a sidecar to the application that emits the delta temporality metrics.
Original: config:
processors:
cumulativetodelta:
include: # <1>
match_type: strict # <2>
metrics: # <3>
- <metric_1_name>
- <metric_2_name>
exclude: # <4>
match_type: regexp
metrics:
- "<regular_expression_for_metric_names>"
# ...
----
<1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
<2> Defines a value provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
<3> Lists the metric names, which are exact matches or matches for regular expressions, of the metrics to be converted to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
<4> Optional: Configures which metrics to exclude. When omitted, no metrics are excluded from conversion to delta metrics.
Revised: <2> Optional: Configures which metrics to include. If you omit this parameter, the processor converts all the metrics into delta metrics, except those metrics that are listed in the `exclude` field.
Original: config:
processors:
cumulativetodelta:
include: # <1>
match_type: strict # <2>
metrics: # <3>
- <metric_1_name>
- <metric_2_name>
exclude: # <4>
match_type: regexp
metrics:
- "<regular_expression_for_metric_names>"
# ...
----
<1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
<2> Defines a value provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
<3> Lists the metric names, which are exact matches or matches for regular expressions, of the metrics to be converted to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
<4> Optional: Configures which metrics to exclude. When omitted, no metrics are excluded from conversion to delta metrics.
Revised: <3> Defines a value that you provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
Original: config:
processors:
cumulativetodelta:
include: # <1>
match_type: strict # <2>
metrics: # <3>
- <metric_1_name>
- <metric_2_name>
exclude: # <4>
match_type: regexp
metrics:
- "<regular_expression_for_metric_names>"
# ...
----
<1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
<2> Defines a value provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
<3> Lists the metric names, which are exact matches or matches for regular expressions, of the metrics to be converted to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
<4> Optional: Configures which metrics to exclude. When omitted, no metrics are excluded from conversion to delta metrics.
Revised: <4> Lists the metric names that exactly match or match regular expressions for the metrics that you want to convert to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
Original: config:
processors:
cumulativetodelta:
include: # <1>
match_type: strict # <2>
metrics: # <3>
- <metric_1_name>
- <metric_2_name>
exclude: # <4>
match_type: regexp
metrics:
- "<regular_expression_for_metric_names>"
# ...
----
<1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
<2> Defines a value provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
<3> Lists the metric names, which are exact matches or matches for regular expressions, of the metrics to be converted to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
<4> Optional: Configures which metrics to exclude. When omitted, no metrics are excluded from conversion to delta metrics.
Revised: <5> Optional: Configures which metrics to exclude. If you omit this parameter, the processor does not exclude any metrics from conversion to delta metrics.
Original: config:
processors:
cumulativetodelta:
include: # <1>
match_type: strict # <2>
metrics: # <3>
- <metric_1_name>
- <metric_2_name>
exclude: # <4>
match_type: regexp
metrics:
- "<regular_expression_for_metric_names>"
# ...
----
<1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
<2> Defines a value provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
<3> Lists the metric names, which are exact matches or matches for regular expressions, of the metrics to be converted to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
<4> Optional: Configures which metrics to exclude. When omitted, no metrics are excluded from conversion to delta metrics.
Revised: <2> Optional. You can limit which metrics the processor converts. You can do this by explicitly defining these metrics here. If you omit this field, the processor converts all metrics, except the metrics that are listed in the `exclude` field.
Original: config:
processors:
cumulativetodelta:
include: # <1>
match_type: strict # <2>
metrics: # <3>
- <metric_1_name>
- <metric_2_name>
exclude: # <4>
match_type: regexp
metrics:
- "<regular_expression_for_metric_names>"
# ...
----
<1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
<2> Defines a value provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
<3> Lists the metric names, which are exact matches or matches for regular expressions, of the metrics to be converted to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
<4> Optional: Configures which metrics to exclude. When omitted, no metrics are excluded from conversion to delta metrics.
Revised: <4> Lists the names of the metrics that you want to convert. The processor converts exact matches or matches for regular expressions. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
Original: config:
processors:
cumulativetodelta:
include: # <1>
match_type: strict # <2>
metrics: # <3>
- <metric_1_name>
- <metric_2_name>
exclude: # <4>
match_type: regexp
metrics:
- "<regular_expression_for_metric_names>"
# ...
----
<1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
<2> Defines a value provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
<3> Lists the metric names, which are exact matches or matches for regular expressions, of the metrics to be converted to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
<4> Optional: Configures which metrics to exclude. When omitted, no metrics are excluded from conversion to delta metrics.
Revised: <5> Optional: You can exclude certain metrics from conversion by explicitly defining them here.
Original: config:
processors:
cumulativetodelta:
include: # <1>
match_type: strict # <2>
metrics: # <3>
- <metric_1_name>
- <metric_2_name>
exclude: # <4>
match_type: regexp
metrics:
- "<regular_expression_for_metric_names>"
# ...
----
<1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
<2> Defines a value provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
<3> Lists the metric names, which are exact matches or matches for regular expressions, of the metrics to be converted to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
<4> Optional: Configures which metrics to exclude. When omitted, no metrics are excluded from conversion to delta metrics.
Revised: <2> Optional: You can limit which metrics the processor converts by explicitly defining which metrics you want converted in this stanza. If you omit this field, the processor converts all metrics, except the metrics that are listed in the `exclude` field.
Original: config:
processors:
cumulativetodelta:
include: # <1>
match_type: strict # <2>
metrics: # <3>
- <metric_1_name>
- <metric_2_name>
exclude: # <4>
match_type: regexp
metrics:
- "<regular_expression_for_metric_names>"
# ...
----
<1> Optional: Configures which metrics to include. When omitted, all metrics, except for those listed in the `exclude` field, are converted to delta metrics.
<2> Defines a value provided in the `metrics` field as a `strict` exact match or `regexp` regular expression.
<3> Lists the metric names, which are exact matches or matches for regular expressions, of the metrics to be converted to delta metrics. If a metric matches both the `include` and `exclude` filters, the `exclude` filter takes precedence.
<4> Optional: Configures which metrics to exclude. When omitted, no metrics are excluded from conversion to delta metrics.
Revised: <3> Defines the value that you provided in the `metrics` field as an exact match by using the `strict` parameter or a regular expression by using the `regex` parameter.
Original: In a disconnected environment, you must mirror the required container images into the environment. For more information, see "Mirroring in disconnected environments" in the {ocp-product-title} product documentation.
Revised: In a disconnected environment, you must mirror the required container images because they are not pulled over the main network. For more information, see "Mirroring in disconnected environments" in the {ocp-product-title} product documentation.
Original: When a pull request (PR) with a YAML error triggers the event, {pac} creates a comment on the PR that describes the error. If the PR is updated and new YAML errors are detected, the comment is updated with the latest information. If no new errors are found, the existing comment remains unchanged and is not deleted.
Revised: When an invalid PipelineRun YAML found in a pull request (PR) event, {pac} creates a comment on the PR that describes the error. If the PR is updated and new YAML errors are detected, the comment is updated with the latest information. If no new errors are found, the existing comment remains unchanged and is not deleted.
Original: {pac} can detect and report errors in the YAML definition of a `PipelineRun`. When a YAML formatting issue is encountered in the repository, the system logs the error in the user namespace events log and the {pac} controller log.
Revised: {pac} can detect and report errors in the YAML definition of `PipelineRun` resources in .tekton directory. When a YAML formatting issue is encountered, the system logs the error in the user namespace events log and the {pac} controller log and a comment is created if the event is pull request.
Original: .YAML parting error messages in pull request comments
{pac} can detect and report errors in the YAML definition of PipelineRun resources located in the .tekton directory. When a YAML formatting issue is encountered, the system logs the error in both the user namespace events log and the {pac} controller log. If the event occurs in a pull request, a comment is also created.
Revised: .YAML parting error messages in pull request comments
{pac} can detect and report errors in the YAML definition of PipelineRun resources located in the .tekton directory. When a YAML formatting issue is encountered, the system logs the error in both the user namespace events log and the {pac} controller log, and a comment is also created on pull request in GitHub, Gitea, and GitLab providers.
Original: {pac} can detect and report errors in the YAML definition of PipelineRun resources located in the .tekton directory. When a YAML formatting issue is encountered, the system logs the error in both the user namespace events log and the {pac} controller log, and a comment is added on a pull request in GitHub, Gitea, and GitLab providers.
Revised: {pac} can detect and report errors in the YAML definition of PipelineRun resources located in the .tekton directory. When a YAML formatting issue is encountered, the system logs the error in both the user namespace events log and the {pac} controller log, and a comment is added on the pull request in GitHub, Gitea, and GitLab providers.
Original: {pac} can detect and report errors in the YAML definition of PipelineRun resources located in the .tekton directory. When a YAML formatting issue is encountered, the system logs the error in both the user namespace events log and the {pac} controller log, and a comment is added on the pull request in GitHub, Gitea, and GitLab providers.
Revised: {pac} can detect and report errors in the YAML definition of PipelineRun resources located in the .tekton directory. When a YAML formatting issue is encountered, {pac} logs the error in both the user namespace events log and the {pac} controller log, and adds a comment to the pull request in GitHub, Gitea, and GitLab providers.
Original: [discrete]
.YAML parting error messages in pull request comments
{pac} can detect and report errors in the YAML definition of PipelineRun resources located in the .tekton directory. When a YAML formatting issue is encountered, the system logs the error in both the user namespace events log and the {pac} controller log, and a comment is added on the pull request in GitHub, Gitea, and GitLab providers.

When an invalid PipelineRun YAML is found in a pull request (PR) event, {pac} creates a comment on the PR describing the error. If the PR is updated and new YAML errors are detected, the comment is updated with the latest information. If no new errors are found, the existing comment remains unchanged and is not deleted.
Revised: [discrete]
.YAML parting error messages in pull request comments
{pac} can detect and report errors in the YAML definition of PipelineRun resources located in the .tekton directory. When a YAML formatting issue is encountered, {pac} logs the error in both the user namespace events log and the {pac} controller log, and adds a comment describing the error to the pull request in GitHub, Gitea, and GitLab providers. If the PR is updated and new YAML errors are detected, the comment is updated with the latest information. If no new errors are found, the existing comment remains unchanged and is not deleted.
Original: {pac} detects and reports YAML errors in PipelineRun definitions within the .tekton directory. If a formatting issue is found, it logs the error in the user namespace events log and the {pac} controller log, and comments on the pull request for GitHub, Gitea, and GitLab. These errors do not halt the execution of valid pipeline runs because the system continues to process correctly formatted and matched pipeline runs, preventing a single formatting problem from disrupting the entire automation workflow. When an invalid PipelineRun YAML is found in a pull request (PR) event, {pac} creates a comment on the PR describing the error. If the PR is updated and new YAML errors are detected, the comment is updated with the latest information. If no new errors are found, the existing comment remains unchanged and is not deleted.
Revised: {pac} detects and reports YAML errors in PipelineRun definitions within the .tekton directory. When an invalid PipelineRun YAML is found in a pull request (PR) event, {pac} creates a comment on the PR describing the error and halt the execution of other correctly formatted pipeline runs. If the PR is updated and new YAML errors are detected, the comment is updated with the latest information. If no new errors are found, the existing comment remains unchanged and is not deleted. If a validation issue is found, it logs the error in the user namespace events log and the {pac} controller log. These errors do not halt the execution of valid pipeline runs because the system continues to process validated and matched pipeline runs, preventing a single validation problem from disrupting the entire automation workflow.
Original: {pac} detects and reports YAML errors in PipelineRun definitions within the .tekton directory. When an invalid `PipelineRun` YAML is found in a pull request (PR) event, {pac} creates a comment on the pull request (PR) describing the error and halts the execution of other correctly formatted pipeline runs. If the PR is updated and new YAML errors are detected, the comment is updated with the latest information. If no new errors are found, the existing comment remains unchanged and is not deleted. If a validation issue is found, it logs the error in the user namespace events log and the {pac} controller log. These errors do not halt the execution of valid pipeline runs because the system continues to process validated and matched pipeline runs, preventing a single validation problem from disrupting the entire automation workflow.
Revised: {pac} detects and reports YAML errors in PipelineRun definitions within the `.tekton` directory. When an invalid `PipelineRun` YAML is found in a pull request (PR) event, {pac} creates a comment on the pull request (PR) describing the error and halts the execution of other correctly formatted pipeline runs. If the PR is updated and new YAML errors are detected, the comment is updated with the latest information. If no new errors are found, the existing comment remains unchanged and is not deleted. If a validation issue is found, it logs the error in the user namespace events log and the {pac} controller log. These errors do not halt the execution of valid pipeline runs because the system continues to process validated and matched pipeline runs, preventing a single validation problem from disrupting the entire automation workflow.
Original: You can opt out of automatic updates for all system-defined boot sources by disabling the `enableCommonBootImageImport` feature gate. If you disable this feature gate, all `DataImportCron` objects are deleted. This does not remove previously imported boot source objects that store operating system images, though administrators can delete them manually.
When the `enableCommonBootImageImport` feature gate is disabled, `DataSource` objects are reset so that they no longer point to the original boot source. An administrator can manually provide a boot source by creating a new persistent volume claim (PVC) or volume snapshot for the `DataSource` object, then populating it with an operating system image.
Revised: When the `enableCommonBootImageImport` field value is set to `false`, `DataSource` objects are reset so that they no longer point to the original boot source. An administrator can manually provide a boot source by creating a new persistent volume claim (PVC) or volume snapshot for the `DataSource` object, and then populating it with an operating system image.