publisher locks too wide in scope
Open, NormalPublic

Description

publishing is throttled at 1 slot to prevent concurrent publishes screwing each other over by manipulating the same repo. this was fine with only release being the gold standard. now with release-lts being a second gold version it is too broad in scope as now twice as many entities can cause a publishing lock-out for all 4 types of builds.

this is fairly awkward as it slows everything to a crawl for no good reason.

it ultimately is fallout from T3407 not getting fixed.

what should happens is:

publishing-category-release blocks _release_ + _unstable_ jobs (qt is unstable so release implicitly needs to block _unstable_ due to lack of distinction also see T3407)

publishing-scope-release-lts blocks _release-lts_ + _unstable_ (qt is unstable)

publishing-scope-stable blocks _stable_ + _unstable_ jobs (qt and frameworks are unstable but pushed into stable)

publishing-scope-unstable only blocks itself

To this end, the publishing throttle should be split into 4 distinct categories, one per build type. All unstable jobs should count into all 4 throttles whereas the !unstable jobs should count into their own plus the unstable one.

As a result everything will block unstable due to T3407 but the other 3 types won't block one another anymore.

sitter created this task.Mar 13 2017, 12:41 PM

all restrictions can be removed if an aptly PR lands which changes aptly to an transaction architecture