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

tkn pipeline start does not use default timeout #865

Closed
Conky5 opened this issue Apr 3, 2020 · 10 comments · Fixed by #952
Closed

tkn pipeline start does not use default timeout #865

Conky5 opened this issue Apr 3, 2020 · 10 comments · Fixed by #952
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Milestone

Comments

@Conky5
Copy link
Contributor

Conky5 commented Apr 3, 2020

Version and Operating System

tkn Version: 0.8.0

Operating System: macOS

Expected Behavior

Pipelines started with tkn pipeline start should use the configured default timeout from tekton pipelines.

Actual Behavior

PipelineRuns created with tkn pipeline start get a timeout of 1h.

Steps to Reproduce the Problem

  1. Create these resources:
---
apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: timeout
spec:
  steps:
    - name: test
      image: busybox:latest
---
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: timeout
spec:
  tasks:
    - name: test
      taskRef:
        name: timeout
  1. Set a default timeout in tekton pipelines https://github.com/tektoncd/pipeline/blob/00194731669ca5a279ca92b2d94cfb85f6ae7f6d/docs/taskruns.md#configuring-default-timeout
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: config-defaults
  namespace: tekton-pipelines
data:
  default-timeout-minutes: "180"
  1. Start the pipeline run
$ tkn pipeline start timeout
Pipelinerun started: timeout-run-6gls4
...
  1. See that the specified default timeout is not used:
$ kubectl get pr -o json timeout-run-6gls4 | jq '.spec.timeout'
"1h0m0s"

Additional Info

@danielhelfand danielhelfand added the kind/feature Categorizes issue or PR as related to a new feature. label Apr 3, 2020
@Conky5
Copy link
Contributor Author

Conky5 commented Apr 3, 2020

This might be considered a kind/bug, as it is similar to how default pod templates were handled in #637.

@danielhelfand
Copy link
Member

@Conky5 I labeled as a feature because it's known that we don't support it at this time and there are ways to appropriately set a desired timeout with tkn. However, I see how it's sort of a little of both if that's fair.

@Conky5
Copy link
Contributor Author

Conky5 commented Apr 3, 2020

Yep, no worries 😄.

@waveywaves
Copy link
Member

/assign

@danielhelfand danielhelfand added the triage/wg-discuss Indicates an issue that needs to be discussed during a working group call. label Apr 5, 2020
@piyush-garg
Copy link
Contributor

piyush-garg commented Apr 6, 2020

@Conky5 Can you please provide information about tekton-pipeline version you have installed.

This may be because of the issue tektoncd/pipeline#2324 also

@danielhelfand
Copy link
Member

I actually opened tektoncd/pipeline#2324 in response to this. It's possible that bug is causing this, but it may also be that the 1h default for tkn being requested may be part of it. I can test once tektoncd/pipeline#2333 is merged.

@Conky5
Copy link
Contributor Author

Conky5 commented Apr 6, 2020

I am using tekton-pipelinesv0.10.1.

@danielhelfand
Copy link
Member

Yeah, so this is more of a CLI issue in terms of the default used. I tested with default-timeout-minutes in v0.10.1 and everything worked accordingly. The issue with default-timeout-minutes appears to be isolated to v0.11.0.

@danielhelfand
Copy link
Member

We'll be moving forward with this approach to address this as discussed in the working group on 4/14/20:

The cli should not set anything for timeout unless specified by the user via the --timeout flag (i.e. no default for --timeout from tkn). This would allow pipelines to do all the work as far as setting the traditional default of 1h as well as checking the ConfigMap for the custom default value for timeout.

@danielhelfand danielhelfand removed the triage/wg-discuss Indicates an issue that needs to be discussed during a working group call. label Apr 14, 2020
@danielhelfand
Copy link
Member

danielhelfand commented Apr 16, 2020

Just adding a list here of what resources are impacted/progress. Pipeline/Task start commands have been addressed, but we'll need to wait until after the next release to address the issue with ClusterTask start:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
5 participants