tektoncd
Bring taskRun.spec.computeResources to beta
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
I'd love for this to go to beta, or even better stable. It was introduced in v0.39.0 (August 2022) and I can't see any issues that have been raised against it.
Trying to create a re-usable Pipeline using catalog items like buildah is really hard without this if you have a namespace with a ResourceQuota - have to rely on a large LimitRange default, which is wasteful as applies to all Tasks and init containers without resources set.
@jimmyjones2 I completely agree that being able to specify compute resources from a taskrun rather than a task is necessary for catalog task reusability. I'm curious whether your use cases are better served by taskRun.spec.computeResources or taskRun.spec.stepSpecs[].computeResources (https://github.com/tektoncd/pipeline/issues/5489)?
@lbernick taskRun.spec.stepSpecs[].computeResources would be less good, as I'd like to create something generic that doesn't need to know the name of the step (ie. it'll create a PipelineRun from any Pipeline with a task called build, which could be the buildah Task or something else)
Thanks for the feedback! We are planning to bring at least one of these features to beta but need to think a bit more about which it will be (or both) since I know some users want a bit more granular control that comes with stepSpecs/sidecarSpecs. The way compute resources work in tekton can be really confusing (since k8s assumes containers run in parallel, but we hack them to run sequentially), so I'm hoping to also gather feedback on which of these features results in the fewest "surprises" or is the least confusing.
Instead of "computeResources" could I suggest "stepResources". For "computeResources" it's not clear to me what "compute" means... verb or noun. Also the computeResources only apply to steps and not sidecars or initcontainers.
TaskRun is of course sensible but... consider also having it in Tasks as that is the unit of sharing and reasonable defaults are very helpful and the TaskRun could then override if needed.
sorry @jimmyjones2, we haven't been able to prioritize this yet, but any updates should be reflected on this issue.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Any progress on this? Would be great to see this moving forward. I fully agree with what @jimmyjones2 commented above.
We are also interested for a beta promotion of this feature. Would love to see some updates. cc: @vdemeester
We are also interested on this feature to move Beta, do you guys have any timeline yet?
@vdemeester: GitHub didn't allow me to assign the following users: khrm.
Note that only tektoncd members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see the contributor guide
In response to this:
/assign @khrm
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/test-infra repository.
