Uploaded image for project: 'OpenShift Pipelines'
  1. OpenShift Pipelines
  2. SRVKP-9534

[Docs] Known issues for release 1.21.0

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Unresolved
    • Icon: Major Major
    • Pipelines 1.21.0
    • None
    • p12n
    • None
    • False
    • Hide

      None

      Show
      None
    • False
    • Hide
      Known issues for 1.21.
      Check the story description for the same.
      Show
      Known issues for 1.21. Check the story description for the same.
    • Known Issue
    • Proposed

      Refer to the Known Issues Template section in this Confluence link: https://spaces.redhat.com/spaces/GITOPS/pages/467059298/Product+Documentation. Here are some examples used in the previous releases of Pipelines: https://docs.redhat.com/en/documentation/red_hat_openshift_pipelines/1.20/html/release_notes/op-release-notes-1-20#pipelines-kn-is[...]ease-notes-1-20

      List of known issues:

      • PAC:
        • CLI cel subcommand gives unclear error messages when body and/or header flags are/is not provided. Jira.
        • CLI cel subcommand panics when invalid gitlab headers and/or body are/is provided. Jira
        • For custom hub catalogs, when catalog-<id>-type is not specified, it defaults to ArtifactHub even when the custom hub URL points to Tekton Hub, requiring users to manually update the TektonConfig to set the correct catalog type. Jira
      • https://issues.redhat.com/browse/SRVKP-9256 
      • UI - https://issues.redhat.com/browse/SRVKP-10006
      • Pruner:
      1. Namespace-Level Pruner ConfigMap Updates Are Not Immediately Applied (https://issues.redhat.com/browse/SRVKP-10008)
        Known Issue
        Updates to a namespace-level pruner ConfigMap are not fully applied to existing PipelineRun and TaskRun resources, even after additional runs complete in the namespace.
        Cause
        Pruning configuration changes are not fully re-applied to resources that already exist at the time of the update.
        Consequence
        After a configuration update, retention limits may be enforced only after a subsequent run completes, but updated TTL values are not applied to existing resources. TTL-based pruning applies only to newly created PipelineRun and TaskRun resources, which may result in older resources remaining longer than expected.
        Workaround
      • Trigger and complete a new PipelineRun to apply updated retention limits
      • Manually delete existing PipelineRun and TaskRun resources that exceed the updated TTL
        Result if the Workaround Is Not Performed
        Updated pruning settings may be only partially enforced, and older PipelineRun and TaskRun resources may remain indefinitely until manually removed.

              Unassigned Unassigned
              diagrawa Divyanshu Agrawal
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: