Test-infra: Document criteria for kubernetes/kubernetes merge-blocking jobs

Created on 23 Jan 2018  路  16Comments  路  Source: kubernetes/test-infra

i.e. when shall we add/remove a presubmit job from queue blocking

cc @spiffxp I remember you have mentioned similar topic, not sure if it's documented anywhere

arejobs sirelease sitesting

Most helpful comment

/lifecycle frozen
/milestone v1.14

FYI @BenTheElder @fejta

Oh look, another milestone bump. The deal is that I'd like for us to implement measurement and enforcement of the criteria laid out for release-blocking. I would then expect merge blocking criteria to be basically the same, but with tighter numbers.

We also have aspirations to move away from the use of clouds in merge-blocking jobs, in the spirit of failing fast, and deferring the slower/flakier jobs later. The difficult balance here is this harkens back to the bad old days where slow/flaky postsubmit builds blocked the queue, which caused much pain for everyone.

All 16 comments

This is basically about

  • extracting info from the google doc at kubernetes/sig-release#24
  • figuring out where to put it
  • PR it to that place
  • making sure folks are aware of the criteria
  • making sure folks know how/when we're enforcing those criteria

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
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.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

this is recently relevant to @shyamjvs with scalability presubmits for example
/remove-lifecycle stale
I know there was a discussion around this, and some initial attempt to document, but we should get that finalized and committed somewhere official..

/milestone 1.12

/assign @spiffxp
assume you have the most ideas here

/milestone v1.13
OK for really reals this time :P

/remove-help

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
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.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/remove-lifecycle stale

/lifecycle frozen
/milestone v1.14

FYI @BenTheElder @fejta

Oh look, another milestone bump. The deal is that I'd like for us to implement measurement and enforcement of the criteria laid out for release-blocking. I would then expect merge blocking criteria to be basically the same, but with tighter numbers.

We also have aspirations to move away from the use of clouds in merge-blocking jobs, in the spirit of failing fast, and deferring the slower/flakier jobs later. The difficult balance here is this harkens back to the bad old days where slow/flaky postsubmit builds blocked the queue, which caused much pain for everyone.

/milestone v1.15

/milestone v1.16
/sig testing
/sig release

/remove-lifecycle frozen
/cc @BenTheElder
FYI @kubernetes/ci-signal

/milestone v1.20
Maybe we can do this before the 3 year anniversary? (because adding a milestone has _totally_ made this happen in the past)

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
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.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/remove-lifecycle stale
/milestone v1.21
Nope. Fourth year's a charm.

Was this page helpful?
0 / 5 - 0 ratings