Support automatic buildrun cleanup

[raghavbhatnagar96]

Based on Ship #28

Core Ship Proposals:

• Two methods used for automatically deleting buildruns - using limits and TTLs
• Create two controllers to ensure this functionality
• Add optional retention parameters in build specifications
• Delete buildrun if either criteria is met
• Update build and buildrun README files

Commit Summary:

• Two controllers have been added - buildrun_ttl_cleanup controller and build_limit_cleanup controller.
  • buildrun_ttl_cleanup controller watches buildruns that are created or updated.
  • build_limit_cleanup controller watches builds that are created or updated and watches buildruns that are updated.
• Build specifications were extended by adding a retention parameter that has 4 optional fields
  • ttlAfterFailed: buildrun is deleted if the mentioned duration of time has passed and the buildrun has failed.
  • ttlAfterSucceeded: buildrun is deleted if the mentioned duration of time has passed and the buildrun has succeeded.
  • failedLimit: If this limit is exceeded, the oldest failed buildruns are deleted till the limit is satisfied.
  • succeededLimit: If this limit is exceeded, the oldest successful buildruns are deleted till the limit is satisfied.
• Buildrun specifications were extended by adding a retention parameter that has 2 optional fields
  • ttlAfterFailed: buildrun is deleted if the mentioned duration of time has passed and the buildrun has failed.
  • ttlAfterSucceeded: buildrun is deleted if the mentioned duration of time has passed and the buildrun has succeeded.
• Tests have been added to ensure that these controllers are working as intended.
• Documentation has been updated to reflect the changes

Signed-off-by: Pravallika Dindukurthi dindukurthi.pravallika@gmail.com

Changes

Submitter Checklist

• Includes tests if functionality changed/was added
• Includes docs if changes are user-facing
• Set a kind label on this PR
• Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.

Release Notes

Introducing support for automatic cleanup by extending build and buildrun specifications. A new optional `retention` section has been introduced in both buildrun and build specifications, that consists of 4 optional fields - `ttlAfterFailed`, `ttlAfterSucceeded`, `failedLimit`, `succeededLimit` in build specifications and 2 optional fields - `ttlAfterFailed`, `ttlAfterSucceeded` - in buildrun specifications.

[qu1queee]

@raghavbhatnagar96 @Pravalika very nice. @SaschaSchwarze0 and myself pair on this review, pls take a look.

[SaschaSchwarze0]

Two small things.

[SaschaSchwarze0]

And just a few glitches on the integration tests.

[SaschaSchwarze0]

Thank you @raghavbhatnagar96 and @PravallikaDindukurthi.

I think you should already start to work on unit tests for the predicate function parts that you already extracted into separate code. We can then add them to this PR or add them in a separate one depending on how fast reviews happen.

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: SaschaSchwarze0

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:

• OWNERS [SaschaSchwarze0]

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

[gabemontero]

API looks OK to me, as do doc.

I minor code debug logging item. I at least won't gate merge on it.

I'll defer tagging until both @otaviof and @adambkaplan take a peek.

[SaschaSchwarze0]

Thanks @raghavbhatnagar96 for addressing all things. Looking for an lgtm @otaviof @gabemontero.

[otaviof]

/lgtm