-
Notifications
You must be signed in to change notification settings - Fork 128
refactor(buildrun): implement Template Method pattern for TaskRun and PipelineRun generation #2056
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
refactor(buildrun): implement Template Method pattern for TaskRun and PipelineRun generation #2056
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
1ca78ca to
e837e32
Compare
e837e32 to
1b53dab
Compare
1b53dab to
c1fac02
Compare
a2eea40 to
d162766
Compare
69527a0 to
b6db4c5
Compare
7794b28 to
c90dbed
Compare
c90dbed to
c853cb2
Compare
ecae202 to
179c370
Compare
|
/retest Release Note Linter |
|
@ayushsatyam146: No presubmit jobs available for shipwright-io/build@main DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/retest |
179c370 to
508aebe
Compare
a001dfb to
fdcf4b7
Compare
|
/retest Unit, Integration, and E2E Tests / e2e (v1.34.0, v1.6.0) |
|
@ayushsatyam146: No presubmit jobs available for shipwright-io/build@main DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/retest |
…late Method pattern
# Summary
Introduced a common BuildRunExecutorGenerator interface that both TaskRun and
PipelineRun implementations follow, while maintaining clear separation between
execution models.
# Changes
- Created executor_generator.go defining 5-phase build execution interface with
initialization step
- Implemented TaskRunGenerator for single-pod, sequential step execution
- Implemented PipelineRunGenerator for multi-pod, multi-task execution with
PVC-based data sharing
- Shipwright-managed push strategies are now supported in PipelineRun mode via
a separate output-image task, enabling 3-task execution (source-acquisition,
build-strategy, output-image) when using shp-output-directory. Strategy-managed
push continues to use 2 tasks.
# Architecture overview:
TaskRun: 1 Pod → [git-clone, buildah-build, image-processing]
PipelineRun: 2-3 Pods → Task1[git-clone] → Task2[buildah-build] → Task3[image-processing]*
(*Task3 only created for shipwright-managed push strategies)
The unified approach enables easy addition of new executor types (e.g., for
multi-arch builds) while maintaining a single source of truth for business logic.
[Release Notes]
- Added PipelineRun execution mode as an alternative to TaskRun, enabling
multi-pod build execution with persistent workspace storage. This lays
the foundation for future multi-architecture build support.
- Build executions now support two modes:
- TaskRun mode (default): Single pod with sequential steps, EmptyDir storage
- PipelineRun mode: Multiple pods (2-3 depending on push strategy) with
task-level separation and PVC-based data sharing
- Note: PipelineRun mode uses PersistentVolumeClaim (1Gi) for workspace
storage instead of EmptyDir, which may require StorageClass configuration
in your cluster.
Signed-off-by: ayushsatyam146 <[email protected]>
fdcf4b7 to
2eabc49
Compare
Changes
initialization step
PVC-based data sharing
a separate output-image task, enabling 3-task execution (source-acquisition,
build-strategy, output-image) when using shp-output-directory. Strategy-managed
push continues to use 2 tasks.
Summary
Introduced a common BuildRunExecutorGenerator interface that both TaskRun and
PipelineRun implementations follow, while maintaining clear separation between
execution models.
Architecture overview:
The unified approach enables easy addition of new executor types (e.g., for
multi-arch builds) while maintaining a single source of truth for business logic.
Release Notes