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

Allow dynamically edit git resolver task refs in Pipelines

XMLWordPrintable

    • False
    • Hide

      None

      Show
      None
    • False

      < High-Level description of the feature ie: Executive Summary >

      Goals

      In Konflux we have a big usage of Tekton Pipelines. Will be nice that git taskrefs in Pipeline can change dynamically. For example:

              taskRef: 
                resolver: git
                params: 
                  - name: url
                    value: https://github.com/$(tasks.test-metadata.results.pull-request-author)/e2e-tests.git
                  - name: revision
                    value: $(tasks.test-metadata.results.git-revision)
                  - name: pathInRepo
                    value: integration-tests/tasks/konflux-e2e-tests-task.yaml
      

      In the example above i have 2 tasks: one is getting revision and the source of my pr where I modify a task and in the second task i want to pass as param the result to use the task from that source

      < Who benefits from this feature, and how? What is the difference between today’s current state and a world with this feature? >

      Currently taskrefs can only point to a concrete value and not dynamically. From this feature can benefit All Konflux customers who want to test tasks changes in Pull Requests...

      See full example in: https://github.com/konflux-ci/e2e-tests/blob/ebf9b6c6c65fdb2a41c6852a1d643f0f58103e49/integration-tests/pipelines/konflux-e2e-tests-pipeline.yaml#L110-L118

      Requirements

      Requirements Notes IS MVP
           
        • (Optional) Use Cases

      < What are we making, for who, and why/what problem are we solving?>

      Out of scope

      <Defines what is not included in this story>

      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

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

      < 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
              flacatus Flavius Lacatusu
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated: