-
Feature
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
False
-
-
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 |
< 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