Stream: t-compiler

Topic: #54393 try build platforms


Pietro Albini (Sep 20 2018 at 15:32, on Zulip):

I'm not sure if try builds run on all platforms? @Pietro Albini would prob know

Pietro Albini (Sep 20 2018 at 15:33, on Zulip):

not by default, but you can edit .travis.yml to change which builders should run

Pietro Albini (Sep 20 2018 at 15:33, on Zulip):

@nikomatsakis

davidtwco (Sep 20 2018 at 15:33, on Zulip):

I think it was @pnkfelix that was interested in this for one of his PRs.

pnkfelix (Sep 20 2018 at 15:54, on Zulip):

@Pietro Albini to be clear we want to get both a build and a run of the test suite.

pnkfelix (Sep 20 2018 at 15:54, on Zulip):

(which I assume is what one will get from mucking with the .travis.yml; I just wanted to make sure to include that info)

Pietro Albini (Sep 20 2018 at 15:54, on Zulip):

uhh... yeah, you could do that from .travis.yml, I don't know if we have capacity for that though

Pietro Albini (Sep 20 2018 at 15:55, on Zulip):

you should ask alex or kenny

pnkfelix (Sep 20 2018 at 15:57, on Zulip):

I got the impression from this comment that the recommended practice is to just make sure you only enable 1 or 2 at a time

pnkfelix (Sep 20 2018 at 15:58, on Zulip):

which ... I would hope would then keep us under our capacity limits?

pnkfelix (Sep 20 2018 at 15:59, on Zulip):

@Pietro Albini but I don't understand enough about the comment, in truth

Pietro Albini (Sep 20 2018 at 15:59, on Zulip):

yep, just avoid enabling all the builders at once and we should have capacity for that

pnkfelix (Sep 20 2018 at 15:59, on Zulip):

i.e. I don't know which commands to @bors and/or Travis represent load on "AppVeyor"

pnkfelix (Sep 20 2018 at 15:59, on Zulip):

Bors and Travis are magic spirits to my cargo-cult usage

Pietro Albini (Sep 20 2018 at 16:01, on Zulip):

you should probably ask @kennytm, they're the one managing bors and travis

kennytm (Sep 20 2018 at 16:10, on Zulip):

i.e. I don't know which commands to @bors and/or Travis represent load on "AppVeyor"

i don't understand what 'represent load on "AppVeyor"' means :upside_down:

nikomatsakis (Sep 20 2018 at 18:00, on Zulip):

we should definitely create a rustc-guide on this topic

pnkfelix (Sep 20 2018 at 18:45, on Zulip):

(dummy msg to let me remerge an offshoot topic)

pnkfelix (Sep 20 2018 at 18:46, on Zulip):

i.e. I don't know which commands to @bors and/or Travis represent load on "AppVeyor"

i don't understand what 'represent load on "AppVeyor"' means :upside_down:

here in this Zulip comment, @simulacrum wrote:

AppVeyor is much more limited on capacity so there we generally don't want to do try

pnkfelix (Sep 20 2018 at 18:48, on Zulip):

so i was trying to say: " @simulacrum appears worried about the AppVeyor capacity. I don't know which commands I issue would utilize resources that could run up against the constraints imposed by the aforementioned AppVeyor capacity."

nagisa (Sep 20 2018 at 19:23, on Zulip):

I suddenly had a strong craving for @bors try x86_64-pc-windows-msvc riscv-none-none woohooarch-very-obscure-yeah and have it run the try builds on only these architectures, taking care of all the resource allocation and whatnot.

nagisa (Sep 20 2018 at 19:24, on Zulip):

the bors command would perhaps end up taking the job matrix names rather than targets, but that’s beyond the point.

simulacrum (Sep 21 2018 at 00:54, on Zulip):

There is no current command you can issue aside from r+ that'll run on AppVeyor -- I don't even think editing the appveyor.yml will do that (not sure about that part though)

pnkfelix (Sep 21 2018 at 10:04, on Zulip):

@simulacrum okay, that actually helps me understand a lot! In particular, my take away is: r+ is "expensive" (or at least may run up against capacity limitations); but pushing to a PR's branch (and thus engaging Travis) is cheap, but you'll need to edit the .travis.yml to switch around the target(s), and should not enable more than 2 or 3 targets via .travis.yml. (and @bors try is also "cheap", but doesn't run the test suite...) Does that sound about right?

simulacrum (Sep 22 2018 at 00:12, on Zulip):

@pnkfelix Sort of -- but the important bit here is that r+ isn't really running up against capacity limitations -- well, not directly. Only one of those can be built at a time, so the only problem is slowing down the queue

simulacrum (Sep 22 2018 at 00:14, on Zulip):

Slowing down the queue is bad, but not as bad as running up against capacity (because there you're also slowing down the queue but almost worse -- because even a successful build will kill the queue)

simulacrum (Sep 22 2018 at 00:15, on Zulip):

try is cheap because it's essentially the equivalent of enabling some builders in the yml file on Travis -- the only benefit to try is that we can use LLVM caches, which PRs I believe normally can't, though I'm not sure about that

Last update: Nov 22 2019 at 05:25UTC