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

Account for PipelineRun elapsed time for timeouts #4506

Merged
merged 1 commit into from
Jan 24, 2022

Conversation

lbernick
Copy link
Member

@lbernick lbernick commented Jan 24, 2022

Changes

Prior to this change, the getTaskRunTimeout function returned a timeout for a new TaskRun
with the assumption that the new TaskRun started at the same time that the PipelineRun started.
This led to pipelinerun.timeouts.tasks being ignored by TaskRun retries or sequential TaskRuns (#4071).
pipelinerun.timeouts.finally has the same problem for retries of finally tasks, but does not have the same
problem for multiple separate finally tasks because finally tasks run in parallel.

This commit subtracts time that has already been elapsed in the pipelineRun from pipelinerun.timeouts.tasks
when creating a new TaskRun. The relationship between finally timeout and retries will be addressed in a separate commit.

Co-authored-by: Jerop Kipruto jerop@google.com @jerop

/kind bug

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

  • Docs included if any changes are user facing
  • Tests included if any functionality added or changed
  • Follows the commit message standard
  • Meets the Tekton contributor standards (including
    functionality, content, code)
  • Release notes block below has been filled in or deleted (only if no user facing changes)

Release Notes

[Bug fix]: Respect `pipelinerun.timeouts.tasks` for sequential TaskRuns or TaskRun retries

@tekton-robot tekton-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/bug Categorizes issue or PR as related to a bug. labels Jan 24, 2022
@tekton-robot tekton-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jan 24, 2022
@tekton-robot tekton-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jan 24, 2022
Prior to this change, the `getTaskRunTimeout` function returned a timeout for a new TaskRun
with the assumption that the new TaskRun started at the same time that the PipelineRun started.
This led to `pipelinerun.timeouts.tasks` being ignored by TaskRun retries or sequential TaskRuns.
`pipelinerun.timeouts.finally` has the same problem for retries of finally tasks, but does not have the same
problem for multiple separate finally tasks because finally tasks run in parallel.

This commit subtracts time that has already been elapsed in the pipelineRun from `pipelinerun.timeouts.tasks`
when creating a new TaskRun. The relationship between finally timeout and retries will be addressed in a separate commit.

Co-authored-by: Jerop Kipruto jerop@google.com
@tekton-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vdemeester

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@tekton-robot tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 24, 2022
@abayer
Copy link
Contributor

abayer commented Jan 24, 2022

/lgtm

@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Jan 24, 2022
@abayer
Copy link
Contributor

abayer commented Jan 24, 2022

/retest

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/bug Categorizes issue or PR as related to a bug. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants