Skip to content
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

When Expressions not scoped to the task when results is missing too #7029

Open
RafaeLeal opened this issue Aug 7, 2023 · 2 comments
Open
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.

Comments

@RafaeLeal
Copy link
Contributor

Expected Behavior

Not sure if this is the expected behavior, I just thought that this was pretty confusing for my scenario, let me know what you think.
I have PipelineRun that runs something like this:


  ┌──────────┐  ┌─────────┐
  │build-app1├─►│push-app1├──┐
  └──────────┘  └─────────┘  │ ┌──────┐
                             │►│deploy│
  ┌──────────┐  ┌─────────┐  │ └──────┘
  │build-app2├─►│push-app2├──┘
  └──────────┘  └─────────┘

This PipelineRun is generated and quite big/complex, so I tried to simplify as much as possible, to something like this:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: testing-when-expressions
  namespace: pipelines
spec:
  pipelineSpec:
    tasks:
      - name: build-app1
        taskSpec:
          results:
            - name: app1-image-tarball
              type: string
          steps: [...]
        when:
          - input: "app1"
            operator: in
            values: [app1, both]

      - name: push-app1
        params:
          - name: app1-image-tarball
            value: $(tasks.build-app1.results.app1-image-tarball)
        taskSpec:
          params:
            - name: app1-image-tarball
              type: string
          steps: [...]
        when:
          - input: "app1"
            operator: in
            values: [app1, both]

      - name: build-app2
        taskSpec:
          results:
            - name: app2-image-tarball
              type: string
          steps: [...]
        when:
          - input: "app1"
            operator: in
            values: [app2, both]

      - name: push-app2
        params:
          - name: app2-image-tarball
            value: $(tasks.build-app2.results.app2-image-tarball)
        taskSpec:
          params:
            - name: app2-image-tarball
              type: string
          steps: [...]
        when:
          - input: "app1"
            operator: in
            values: [app2, both]
      - name: deploy
        runAfter:
          - push-app1
          - push-app2
        taskSpec:
          steps: [ ... ]

What do I expected:

  1. build-app1 runs
  2. build-app2 is skipped
  3. push-app1 runs
  4. push-app2 is skipped
  5. deploy runs

Actual Behavior

What actually happened:

  1. ✅ build-app1 runs
  2. ✅ build-app2 is skipped
  3. ✅ push-app1 runs
  4. 🟡 push-app2 is skipped
  5. ❌ deploy runs

Debugging what happened, I first noticed in the status:

  provenance:
    featureFlags:
      ...
      ScopeWhenExpressionsToTask: false

This is confusing since this feature-flag used to have default "true" value and I didn't change it. But AFAIK this is just a visibility problem since this feature flag doesn't actually exist anymore.

Looking at the skipped tasks:

skippedTasks:
   - name: build-app2
     reason: When Expressions evaluated to false
     whenExpressions: [...]
   - name: deploy
     reason: Parent Tasks were skipped
   - name: push-app2
     reason: Results were missing
     whenExpressions: [...]

So here it lies the problem: push-app2 was skipped due to results being missing, instead of when expressions.. So the deploy was skipped too, since the parent was skipped not due to when expressions.

From what I could gather, this happens because we evaluate first the results references then the when expressions here

So what happened was that push-app2 was skipped for the "wrong" reason so deploy was unexpectedly skipped.

Steps to Reproduce the Problem

  1. Create a PipelineRun as described above

Additional Info

  • Kubernetes version:

    Output of kubectl version -o yaml | yq .serverVersion:

buildDate: "2023-06-16T17:32:40Z"
compiler: gc
gitCommit: 78c8293d1c65e8a153bf3c03802ab9358c0e1a14
gitTreeState: clean
gitVersion: v1.27.3-eks-a5565ad
goVersion: go1.20.5
major: "1"
minor: 27+
platform: linux/amd64
  • Tekton Pipeline version:

    Output of tkn version or kubectl get pods -n tekton-pipelines -l app=tekton-pipelines-controller -o=jsonpath='{.items[0].metadata.labels.version}'

v0.48.0
@RafaeLeal RafaeLeal added the kind/bug Categorizes issue or PR as related to a bug. label Aug 7, 2023
@tekton-robot
Copy link
Collaborator

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.

@tekton-robot tekton-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Nov 5, 2023
@tommyb82
Copy link

We have just encountered this issue, Tekton pipelines v0.56.4.

  • Task A - Skip when conditional = false. If executed, results are calculated and used in Task B
  • Task B - Skip on same when conditional as Task A. If executed, uses results from Task A. But skipped reason is "Results were missing"
  • Task C - Should always execute (no when block) but is skipped if Task B skips due to "Results were missing".

Task C has no dependency on Task A's results, and if we remove declaration/use of results between Task A and B by hardcoding some values temporarily, then Task C executes regardless of whether Task A or B are skipped (conclusion: feature ScopeWhenExpressionsToTask is defaulting to true as expected, despite being reported as false in the PR yaml as observed by OP).

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. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
None yet
Development

No branches or pull requests

3 participants