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

PaC: maintain git-provider accessible condition on Repository CR

XMLWordPrintable

    • Icon: Feature Feature
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • Pipelines as Code
    • None
    • False
    • Hide

      None

      Show
      None
    • False

      Maintain a condition on Repository CRs which reflects if/how the remote repository is reachable

      Goals

      Pipelines as Code users and integrators (e.g. Konflux) would benefit from programmatic access to the last-known connectivity of a PaC Repository CR.
      If a repository is not reachable by PaC, for example if the secret token has expired, the custom domain is unreachable, or the API is being throttled, PaC is unable to operate. However in this event there is not much users can do to know why PaC is not working without access to PaC logs. They may only see that their PipelineRuns are failing to start or that the VCS shows their jobs to be running well after the PLR should have completed/timed-out.

      By maintaining a condition on a Repository CR to reflect repository connectivity, users can see their their repository is having connectivity issues without sifting through events. Similarly, tools like the Openshift Pipelines Console Plugin and Konflux UI can consume this condition to display warning banners or even notifications when PaC stops working with their Repository.

      Requirements

      Requirements Notes IS MVP
      Create a "repository reachable" condition Repository CR The condition name can be whatever the team decides. X
      When the repository is unreachable due to rate limiting, the condition reflects that   X
      When the VCS secret gets unauthorized responses from the VCS API, the condition reflects that the secret is expired some operations may expect an unauthorized response, e.g. for Gitlab Forks  
      When PaC successfully connects to the VCS API, the condition is cleared   X
      If the VCS API rate-limits PaC and gives a "try again in $duration" header, the condition should show the duration    
      If a given rate-limiting period expires, PaC resets the condition whether or not it's attempted to connect to the repository    

      (Optional) Use Cases

      • Users can see when they're being rate limited
      • Integration teams can see and consume PaC's VCS rate limiting information
      • Users can see and be notified when their VCS API Key expires

      Out of scope

      • Rate limits might be scoped to multiple repositories (e.g. in Github App installations). One Repository CR getting rate limited shouldn't automatically update conditions on other Repository CRs.

      Dependencies

      < Link or at least explain any known dependencies. >

      Background, and strategic fit

      < What does the person writing code, testing, documenting need to know? >

      Assumptions

      • This feature assumes rate limiting and reachibility is an all-or-nothing. For public repositories or forks, there may be some API operations which work in spite of authentication issues or rate limiting. E.g. If an API key has expired, will it prevent API requests, like listing files in a public repo, which do not require authentication?

      < Are there assumptions about hardware, software or people resources?>

      Customer Considerations

      < Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

      Documentation Considerations

      < What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >

      What does success look like?

      < Does this feature have doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>

      QE Contact

      < Are there assumptions being made regarding prerequisites and dependencies?>

      < Are there assumptions about hardware, software or people resources?>

      Impact

      < If the feature is ordered with other work, state the impact of this feature on the other work>

      Related Architecture/Technical Documents

      <links>

      Done Checklist

      • Acceptance criteria are met
      • Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
      • User Journey automation is delivered
      • Support and SRE teams are provided with enough skills to support the feature in production environment

              Unassigned Unassigned
              rh-ee-athorp Andrew Thorp
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: