Set a maximum priority for builds. #660
Conversation
|
I'd prefer to have the Homu version bump and config change in the same PR, if possible. |
|
@aneeshusa Thanks! I completely neglected to bump the Homu version in the Homu changes, as well. I'll update both patches. |
|
@aneeshusa I may be misreading this, but it looks like we're pulling a Homu git revision from the pillar in https://github.com/servo/saltfs/blob/master/homu/init.sls#L22 rather than working from its version at all? |
|
@edunham |
|
You are correct that we're currently directly pinning the git revision instead of the PyPi version, however. I think using PyPi versions would be better! |
|
I think that we may not be using the PyPi version because we are not publishing our Homu to pypi with any sort of regular cadence or automation. For now I think we should land the Homu changeset then I'll update this PR with the new Homu rev of the merge, and I'll add fixing the pypi stuff to the stack of fixups Homu needs :) |
implement maximum priority If this deploys before servo/saltfs#660 lands, it might break. Tagging blocked on external till saltfs 660 lands. This is required to do #111 the easy way. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/homu/114) <!-- Reviewable:end -->
|
Fixed it. Sorry about the delay there. r? @aneeshusa |
|
r=me after squash; please also clean up the commit message, particularly the bit about landing before the Homu bump, as Salt handles the ordering correctly already. |
The whole thing about having non-infinite priorities is to facilitate sherriffing as discussed in servo/homu#111 These changes set a max_priority for Homu and bump Homu to the version which respects it. I pulled 9001 out of thin air because I consider it easy to memorize.
|
@bors-servo r=aneeshusa |
|
📌 Commit 9945e10 has been approved by |
Set a maximum priority for builds. This should be in our configs at or before the time we deploy the changes to get Homu to read the max priority setting. The whole thing about having non-infinite priorities is to facilitate sherriffing as discussed in servo/homu#111 I pulled 9001 out of thin air because I consider it easy to memorize. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/saltfs/660) <!-- Reviewable:end -->
|
💔 Test failed - status-travis |
|
@bors-servo retry
|
Set a maximum priority for builds. This should be in our configs at or before the time we deploy the changes to get Homu to read the max priority setting. The whole thing about having non-infinite priorities is to facilitate sherriffing as discussed in servo/homu#111 I pulled 9001 out of thin air because I consider it easy to memorize. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/saltfs/660) <!-- Reviewable:end -->
|
☀️ Test successful - status-travis |
5 participants
This should be in our configs at or before the time we deploy the changes to
get Homu to read the max priority setting.
The whole thing about having non-infinite priorities is to facilitate
sherriffing as discussed in servo/homu#111
I pulled 9001 out of thin air because I consider it easy to memorize.
This change is