-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Taskrun not working with volumeClaimTemplate #5537
Labels
kind/bug
Categorizes issue or PR as related to a bug.
priority/critical-urgent
Highest priority. Must be actively worked on as someone's top priority right now.
Comments
piyush-garg
changed the title
Taskrun not workng with volumeClaimTemplate
Taskrun not working with volumeClaimTemplate
Sep 22, 2022
Will have to be included in a 0.40.1 👼🏼 |
dibyom
added
the
priority/critical-urgent
Highest priority. Must be actively worked on as someone's top priority right now.
label
Sep 22, 2022
4 tasks
4 tasks
piyush-garg
added a commit
to piyush-garg/pipeline
that referenced
this issue
Sep 26, 2022
…creation This will move the auto name generation of workspace to happend after the pvc is created for volumeClaimTemplate and then name will be generated for workspace of volumeClaimTemplate type Added an example Fix tektoncd#5537
piyush-garg
added a commit
to piyush-garg/pipeline
that referenced
this issue
Sep 26, 2022
This will move the auto name generation of workspace to happen after the pvc is created for volumeClaimTemplate and then name will be generated for workspace of volumeClaimTemplate type Added an example Fix tektoncd#5537
7 tasks
tekton-robot
pushed a commit
that referenced
this issue
Sep 26, 2022
This will move the auto name generation of workspace to happen after the pvc is created for volumeClaimTemplate and then name will be generated for workspace of volumeClaimTemplate type Added an example Fix #5537
tekton-robot
pushed a commit
to tekton-robot/pipeline
that referenced
this issue
Sep 26, 2022
This will move the auto name generation of workspace to happen after the pvc is created for volumeClaimTemplate and then name will be generated for workspace of volumeClaimTemplate type Added an example Fix tektoncd#5537
tekton-robot
pushed a commit
that referenced
this issue
Sep 26, 2022
This will move the auto name generation of workspace to happen after the pvc is created for volumeClaimTemplate and then name will be generated for workspace of volumeClaimTemplate type Added an example Fix #5537
abayer
added a commit
to abayer/tektoncd-pipeline
that referenced
this issue
Sep 28, 2022
fixes tektoncd#5574 With tektoncd#5537, the call to `applyParamsContextsResultsAndWorkspaces` and setting of `tr.Status.TaskSpec` to the output of that call was moved from happening with every call to `reconcile` to only happening if there wasn't already a pod created. This didn't cause any problems with execution, but it sometimes resulted in `tr.Status.TaskSpec` not getting set properly or getting reset to `nil` on a subsequent `reconcile` run, with the end result that, sometimes, `tr.Status.TaskSpec` would contain the original `TaskSpec` without parameter, result, context, and workspace references being replaced with the corresponding value. This caused flaky failures in the `TestPipelineRunStatusSpec/pipeline_status_spec_updated` e2e test, and integration test failures in Chains (tektoncd/chains#577). This change moves the PVC creation out of the `if pod == nil {` block that creates the pod if needed, while still checking if `pod` is `nil` before creating the PVC, and brings the `applyParamsContextsResultsAndWorkspaces` call and setting of `tr.Status.TaskSpec` back out of the pod creation block, but after the possible PVC creation. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
7 tasks
abayer
added a commit
to abayer/tektoncd-pipeline
that referenced
this issue
Sep 28, 2022
fixes tektoncd#5574 With tektoncd#5537, the call to `applyParamsContextsResultsAndWorkspaces` and setting of `tr.Status.TaskSpec` to the output of that call was moved from happening with every call to `reconcile` to only happening if there wasn't already a pod created. This didn't cause any problems with execution, but it sometimes resulted in `tr.Status.TaskSpec` not getting set properly or getting reset to `nil` on a subsequent `reconcile` run, with the end result that, sometimes, `tr.Status.TaskSpec` would contain the original `TaskSpec` without parameter, result, context, and workspace references being replaced with the corresponding value. This caused flaky failures in the `TestPipelineRunStatusSpec/pipeline_status_spec_updated` e2e test, and integration test failures in Chains (tektoncd/chains#577). This change moves the PVC creation out of the `if pod == nil {` block that creates the pod if needed, while still checking if `pod` is `nil` before creating the PVC, and brings the `applyParamsContextsResultsAndWorkspaces` call and setting of `tr.Status.TaskSpec` back out of the pod creation block, but after the possible PVC creation. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
abayer
added a commit
to abayer/tektoncd-pipeline
that referenced
this issue
Sep 29, 2022
fixes tektoncd#5574 With tektoncd#5537, the call to `applyParamsContextsResultsAndWorkspaces` and setting of `tr.Status.TaskSpec` to the output of that call was moved from happening with every call to `reconcile` to only happening if there wasn't already a pod created. This didn't cause any problems with execution, but it sometimes resulted in `tr.Status.TaskSpec` not getting set properly or getting reset to `nil` on a subsequent `reconcile` run, with the end result that, sometimes, `tr.Status.TaskSpec` would contain the original `TaskSpec` without parameter, result, context, and workspace references being replaced with the corresponding value. This caused flaky failures in the `TestPipelineRunStatusSpec/pipeline_status_spec_updated` e2e test, and integration test failures in Chains (tektoncd/chains#577). This change moves the PVC creation out of the `if pod == nil {` block that creates the pod if needed, while still checking if `pod` is `nil` before creating the PVC, and brings the `applyParamsContextsResultsAndWorkspaces` call and setting of `tr.Status.TaskSpec` back out of the pod creation block, but after the possible PVC creation. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
tekton-robot
pushed a commit
that referenced
this issue
Sep 29, 2022
fixes #5574 With #5537, the call to `applyParamsContextsResultsAndWorkspaces` and setting of `tr.Status.TaskSpec` to the output of that call was moved from happening with every call to `reconcile` to only happening if there wasn't already a pod created. This didn't cause any problems with execution, but it sometimes resulted in `tr.Status.TaskSpec` not getting set properly or getting reset to `nil` on a subsequent `reconcile` run, with the end result that, sometimes, `tr.Status.TaskSpec` would contain the original `TaskSpec` without parameter, result, context, and workspace references being replaced with the corresponding value. This caused flaky failures in the `TestPipelineRunStatusSpec/pipeline_status_spec_updated` e2e test, and integration test failures in Chains (tektoncd/chains#577). This change moves the PVC creation out of the `if pod == nil {` block that creates the pod if needed, while still checking if `pod` is `nil` before creating the PVC, and brings the `applyParamsContextsResultsAndWorkspaces` call and setting of `tr.Status.TaskSpec` back out of the pod creation block, but after the possible PVC creation. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
tekton-robot
pushed a commit
to tekton-robot/pipeline
that referenced
this issue
Sep 29, 2022
fixes tektoncd#5574 With tektoncd#5537, the call to `applyParamsContextsResultsAndWorkspaces` and setting of `tr.Status.TaskSpec` to the output of that call was moved from happening with every call to `reconcile` to only happening if there wasn't already a pod created. This didn't cause any problems with execution, but it sometimes resulted in `tr.Status.TaskSpec` not getting set properly or getting reset to `nil` on a subsequent `reconcile` run, with the end result that, sometimes, `tr.Status.TaskSpec` would contain the original `TaskSpec` without parameter, result, context, and workspace references being replaced with the corresponding value. This caused flaky failures in the `TestPipelineRunStatusSpec/pipeline_status_spec_updated` e2e test, and integration test failures in Chains (tektoncd/chains#577). This change moves the PVC creation out of the `if pod == nil {` block that creates the pod if needed, while still checking if `pod` is `nil` before creating the PVC, and brings the `applyParamsContextsResultsAndWorkspaces` call and setting of `tr.Status.TaskSpec` back out of the pod creation block, but after the possible PVC creation. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
tekton-robot
pushed a commit
that referenced
this issue
Sep 30, 2022
fixes #5574 With #5537, the call to `applyParamsContextsResultsAndWorkspaces` and setting of `tr.Status.TaskSpec` to the output of that call was moved from happening with every call to `reconcile` to only happening if there wasn't already a pod created. This didn't cause any problems with execution, but it sometimes resulted in `tr.Status.TaskSpec` not getting set properly or getting reset to `nil` on a subsequent `reconcile` run, with the end result that, sometimes, `tr.Status.TaskSpec` would contain the original `TaskSpec` without parameter, result, context, and workspace references being replaced with the corresponding value. This caused flaky failures in the `TestPipelineRunStatusSpec/pipeline_status_spec_updated` e2e test, and integration test failures in Chains (tektoncd/chains#577). This change moves the PVC creation out of the `if pod == nil {` block that creates the pod if needed, while still checking if `pod` is `nil` before creating the PVC, and brings the `applyParamsContextsResultsAndWorkspaces` call and setting of `tr.Status.TaskSpec` back out of the pod creation block, but after the possible PVC creation. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
kind/bug
Categorizes issue or PR as related to a bug.
priority/critical-urgent
Highest priority. Must be actively worked on as someone's top priority right now.
Expected Behavior
Taskrun Should Work
Actual Behavior
Taskrun is throwing an error
Steps to Reproduce the Problem
Additional Info
It is working fine with pipeline 0.39 but not with pipeline 0.40. It is a regression.
The text was updated successfully, but these errors were encountered: