XMLWordPrintable

    • 3
    • Documentation (Ref Guide, User Guide, etc.), User Experience
    • Hide
      Introducing group-based access control in PAAC actions! Users can now define groups on Git Platforms, such as GitHub teams, to drive actions and access in PAAC. This feature enhances security and simplifies managing permissions in large organizations, ensuring that only trusted individuals can run CI or allow others to run it. Currently, this group-based access control is supported only for the /ok-to-test command and running the CI on push or pull_request events.
      Show
      Introducing group-based access control in PAAC actions! Users can now define groups on Git Platforms, such as GitHub teams, to drive actions and access in PAAC. This feature enhances security and simplifies managing permissions in large organizations, ensuring that only trusted individuals can run CI or allow others to run it. Currently, this group-based access control is supported only for the /ok-to-test command and running the CI on push or pull_request events.
    • ---
    • ---

      Story (Required)

      Goal

      Let PAAC actions and access be driven by groups of people as defined on the Git Platforms (ie: Github teams) instead of all or nothing

      Description
      PAAC currently let anyone runs a pipelinerun as long they are on the Github organisation or a contributor of the repo where the pull request run.

      It allows the users issuing a /ok-to-test or /retest to let non contributor to run the tests.

      Problem

      on a large organisation, not everyone can be trusted for every repositories to let run a CI or let someone else running the CI.

      Managing the groups of allowed users is easier to do on the Github interface.

      Background (Required)

      <Describes the context or background related to this story>

      Out of scope

      <Defines what is not included in this story>

      Approach (Required)

      <Description of the general technical path on how to achieve the goal of the story. Include details like json schema, class definitions>

      Dependencies

      <Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

      Acceptance Criteria (Mandatory)

      <Describe edge cases to consider when implementing the story and defining tests>

      <Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

      INVEST Checklist

      Dependencies identified

      Blockers noted and expected delivery timelines set

      Design is implementable

      Acceptance criteria agreed upon

      Story estimated

      Legend

      Unknown

      Verified

      Unsatisfied

      Done Checklist

      • Code is completed, reviewed, documented and checked in
      • Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
      • Continuous Delivery pipeline(s) is able to proceed with new code included
      • Customer facing documentation, API docs etc. are produced/updated, reviewed and published
      • Acceptance criteria are met

              rhn-support-ssathe Shivani Sathe
              mramendi Mikhail Ramendik
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: