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

Filtering pull request event based on file change

XMLWordPrintable

    • 5
    • False
    • None
    • False
    • Hide
      The GitHub Interceptor now has the ability to add a comma delimited list of all files that have changed (added, modified or deleted) for the push and pull_request events. The list of changed files are added to the changed_files property of the event payload in the top-level extensions field
      Show
      The GitHub Interceptor now has the ability to add a comma delimited list of all files that have changed (added, modified or deleted) for the push and pull_request events. The list of changed files are added to the changed_files property of the event payload in the top-level extensions field
    • Pipelines Sprint 228, Pipelines Sprint 229, Pipelines Sprint 230, Pipelines Sprint 231, Pipelines Sprint 232, Pipelines Sprint 233, Pipelines Sprint 234

      Story (Required)

      As a DevOps engineer, I want to filter GitHub events based on files that have changed in the pull-request so that pipelines execute only for relevant changes in the Git repository.

      Background (Required)

      tektoncd/triggers should ship some built-in interceptors that allows a user to filter events based of changed files.

      Out of scope

      <Defines what is not included in this story>

      Approach (Required)

      Merge what has been done from tektoncd/plumbing interceptors around filtering based of changed files and propose it as an upstream PR for adding this built-in.

      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

              kcloutier Ken Cloutier (Inactive)
              rbehera-1 Rupali Behera
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: