[concurrency] Concurrency controller fails to cancel matching PipelineRuns about experimental HOT 9 CLOSED

I think the pipelinerun controller behavior should be modified, and a field similar to bindQueue should be added to the pipelinerun spec or get queue by selector. If the queue is bound, it should enter the queue first, and wait for the queue to be processed according to the policy before performing subsequent processing logic.

from experimental.

/assign

from experimental.

I think I know what's going on:

The concurrency control relies on a label, "tekton.dev/pipeline:teps-linter", which is added by the PipelineRun controller rather than hard-coded in the trigger template. When I switch the concurrency control to rely on a label ("tekton.dev/check-name: pull-community-teps-lint") that is set by the trigger template rather than the PipelineRun controller, the previous PipelineRun is successfully canceled. I think the first reconcile loop of the concurrency controller is happening before the PipelineRun controller has set this label, so the concurrency control never matches the PipelineRun.

I'm still not sure why this seems to happen every time, rather than failing only some of the time (as I'd expect if there were a race condition between the PipelineRun controller and the concurrency controller). One possibility is that the event w/ message "the object has been modified; please apply your changes to the latest version and try again" is coming from the update call in the PipelineRun controller that sets these labels, which fails because the concurrency webhook has already patched the labels when the PipelineRun was created. (Not sure if this is how reconciler queues and patches/updates actually work?)

I'm also not sure what to do about this-- one option would be to skip a concurrency controller reconcile loop if the label applied by the PipelineRun controller is not present yet. (A bit hacky and we'd have to build these assumptions into the unit tests.) What if a project has another controller that sets labels on PipelineRuns somehow and wants to use them with concurrency controls?

from experimental.

Update: the reason why this is deterministic is that the pipeline is not fetched until after the PipelineRun starts executing; i.e. the concurrency controller marks the PipelineRun as no longer pending, the PipelineRun begins executing, and then the PipelineRun controller applies the label "tekton.dev/pipeline". Therefore, I'm not sure how we can simultaneously prevent a PipelineRun from starting until concurrency controls are applied, and also allow concurrency controls to be applied w/ the label "tekton.dev/pipeline" (unless we change the pipelinerun controller behavior).

from experimental.

#tektoncd/community#951

from experimental.

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.

from experimental.

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.

from experimental.

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

from experimental.

@tekton-robot: Closing this issue.

from experimental.