We need a make release job

[kubernetes]

We need a make release job

[luxas]

Presubmit make release was a good thing after all, no one wants to deal with such a mess like this when releasing :/
These things happen, but when coverage is greatly reduced, more reverts and forward fixes like this are required.

Hopefully builds will be much faster in go1.7, so we might consider a presubmit jenkins job that just runs make release and is PR-blocking? Anyone agrees?

[ixdy]

Two separate PRs have broken Windows and Darwin builds. :(

kubernetes/kubernetes#27970
kubernetes/kubernetes#30087

[spxtr]

I agree. We'll keep doing a quick-release for the e2e tests, but we will need a separate job for a full release.

[luxas]

Hmm, I don't think this should be closed yet... seems like the bots don't agree with me 😄

[ixdy]

kubernetes/kubernetes#31013 is the last blocker for this, assuming someone else doesn't try to fix it and collide with me.

[ixdy]

I'm glad I checked. kubernetes/kubernetes#30802 is the one we want.

[ixdy]

Reopening until we have a PR make release job and the CI one is queue-blocking.

It'd be pretty trivial to add it to PR Jenkins, but I think we want to make sure we have enough Jenkins agents for the added compilation load, and we really need to address the exploding "ok to test" comments.

[luxas]

Yes, of course it requires machine power... you might have to go on a shopping tour :)

[ixdy]

stop it, github!

[spxtr]

We have a presubmit now. I don't think a postsubmit blocking job is a good idea.

[ixdy]

We have a presubmit, but I don't think SQ verifies that it's passing before attempting to merge, does it?

[spxtr]

No, since it only runs on PRs that are likely to break it. The submit queue needs to be extended to support optional jobs: merge if the status is not present or if it is passing. That should be a separate issue, though.