https://pantsbuild.org/ logo
Join Slack
Powered by
then you could store twitter creds on that origin ...
# announce
e
then you could store twitter creds on that origin and have its own ci config
w
wouldn't that suffer from the same issue?
e
No
w
(unless it was a private repo, maybe)
e
Twitter would have its own .travis.yml with its own creds.
w
but we still wouldn't be able to publish from a PR?
e
You'd develop not in forks of the twitter repo, but directly on branches
w
ah
e
I'd really love not to do this on the Pants repo, where we could of course do the same thing
w
would be great to make this work for non-twitter folks. in reality: yes, it's currently all twitter folks.
e
Yes and again I'd raise - what project have you ever heard of that burns binaries for every change for people to test with
But to problem solving - is there no way to have a whitelist file for a repo/branch at twitter that clones it and runs from sources?
w
all of them burn binaries for every change... not all of them for people to test with.
e
as opposed to building a pex from binaries?
for testing?
Again on the problem solving - burning a binary and storing one are seperate things we conflate currently. Would a local dev laptop run of a burn in a docker image suffice?
w
no docker support for going back to OSX 10.11
e
So these local tests need to run OSX, Centos6 or both?
w
building a linux binary is the majority usecase though, so that could be done internally.
g
maybe we could upstream the local script because it seems like eric would find it useful as well
w
thoughts on having a ludicrously low TTL on a "public" bucket, and then having the bot use some other storage that only it could write to?
e
that only it could write to?
That is the bit that seems impossible.
How do we do that?
w
the bot could run anywhere, with its own secrets. i don't know much about github bots, but i assume they are webhooks to a service
e
But if it builds any PR it becomes a public pucket
Unless we let it only run against a whitelist of PRs
and then the whitelist needs to be on origin
w
Contributors team... ?
e
Yup, negating @gorgeous-alligator-94763's premise
w
well, Contributors is a much lower / non-existent bar
e
Ah, contributor
Jesus - this is all so tortured
w
i don't think it is just a hypothetical that people contributing patches would want to use their patches
regardless of origin company
e
I agree with that - but using the patches via the intermediary of a binary hosted in a public place is ... more
SO, if a dev ran OSX, had vmware-foo - I assume they could locally build old OSX binaries and old linux binaries
Using existing pants release scripts
w
yes.
e
IOW I assume the major issue here is building for old x
w
yea.
e
And the use case is mainly perf regression? I assume BUILD vagaries could be simulated in the PR.
Basically - what classes of things are only testable via burning binaries for the PR before it hits master?
w
well, the thing you can't reproduce OSX wise is older versions. but the majority of the usecases where testing PRs is useful with a binart (ie, not from source) are on linux
so building "split"/linux-only pexes to test things would be "ok"
e
And towards what end? perf - hangs, what do you guys need to test on linux mostly?
w
and that is very dockerable.
the common case is an internal contributor that wants to run a Source sandbox
e
But again - why? Because that will spot a perf regression I assume. ~All other things should be open sourceable
Its really only the scale of a Twitter repo we don't have access to out here fwict
w
"the linux environment in Twitter prod" is a challenge to mimic upstream
e
OK
w
and yes "all things are open sourceable" in theory. but minimizing a repro sometimes takes actual iteration
e
And they forbid docker containers on Aurora?
or wherever?
w
unknown. but builds are not currently running in docker containers.
e
OK - well the 2 viable ideas in my mind atm are a twitter fork custom .travis.yml / custom workflow for tweeps or else the linux docker local burn thing
On the latter, I'd be happy to chip in. I've wanted to fully dockerize our ci for reproduceablility.
(local repro of ci failures)
w
the binary is already built in docker, iirc
e
Yes
But I assumed that wasn't good enough or something since this all keeps coming up!
I would like to get all linux shards running on the same docker image at some point.
w
i think that the local docker workflow might look like having a docker image (with support script...?) to launch a docker image mounted on an arbitrary repo.
e
What do you mean by arbitrary repo? Is the state of the local clone good enough?
I had a PR for this long ago, Benjy got in something similarish that I think is now just disused.
w
no... the goal would be to test on your internal repo
e
Ok, I lost the thread. I thought the docker idea was to just burn binaries like we already do in CI, but locally. Just not store them publically - use them directly after burning in whatever local process to produce a pex
w
or that, yea.
e
OK. The that you can do today right now IIUC
w
i started to mash up ideas. building binaries is more general.
e
I think building binaries locally is pretty much already done mod a script to encapsulate the few lines of .travis.yml deploy shard setup
w
yea. the annoying bit is just that it implies a "partial"/linux-only pex
e
So is VMWare or whatever is the de-rigeur untenable here
IE: tweeps who want to do this get VMWare fusion and run a burn insdie of that.
That could produce a full real pex with old enough OSX and linux
That sketch is what I've always had in my mind I guess.
w
it's less about completing the pex from my perspective, and more just that we've moved to a world where you might have a branch referencing a pex that is partial, and thus not safe to actually land.
so just more workflow/defensive steps, probably.
e
I assume though that the PR step we're adding here to the binary picture is already just making things smoother, quicker and you'd have the existing master burn process anyway before really landing internally.
w
correct.
e
An just so I'm clear - a branch referencing a pex that is partial means we flub an OS-specific issue. WHether it be platform specific wheel, rust behavior that is plat specific, or what have you. What - in fact - has been the class of issue like these that burn you?
w
well, the general class would be something like: "something goes through Twitter's internal SQ and then fails on end-user laptops because of different coverage"
e
Yeah - OK. And SQ hits some laptops or imacs or something?
w
should, but does not
...our internal Pants release process does more manual vetting, but in general: the state of coverage on OSX is unfortunate
e
OK - well given the unfortunate state, it seems to me then that - fos devs using OSX - which maybe excludes Danny? - burning a pex locally via Docker for Centos6 + the local OSX host will give you everything you need in terms of quick turnaround and testing both - since OSX testing is only local on a laptop anyhow from the sounds of it.
You only miss - this multiplatofrm pex tested OK on OSX 10.13 but failed on 10.11
w
yes. i would still love to have cake and eat it too. but if that's how it needs to go down, then that's how it needs to go down.
(Dorothy's call)
thank you for the discussion!
a
if i understand correctly the "docker local burn" solution described is literally what i've been saying for weeks
totally workable without any interaction with travis ci
i just haven't done it yet and nobody's asked for it yet but like when i next need to make a pex i'll do it
and anecdotally all our pantsbuild/binaries are built on "some random osx laptop" and that's been fixed whenever it's been a problem, so i wouldn't suspect the osx side would need a ton of wrapping
we currently happen to have a 10.12 laptop here but it would be nice to have a 10.11 box since that's our "minimum" supported version i can ask if we can flash it to 10.11 afterwards although that may already have been answered as no (@salmon-summer-38098 am i making this up?)
yeah i feel pretty sure saying the discussion above paralleled one we have had
e
I just am really surprised this is not the answer: https://buy.parallels.com/329/purl-pdb14-1y
Or some variant
No need to flash anything, stay up to the current oldest on any dev osx box
a
maybe it was at a 35 degree angle
w
"not duplicating upstream infra" is a goal
And a corollary is: "improve upstream infra"
a
is that the only way to get an older osx? i guess i could buy a physical cd. i couldn't figure out how to get an iso
w
script wrapping docker image for local linux-only pex building qualifies
a
like i was here assuming that wasn't possible
if we can script every supported osx and linux environment i think that is just fine
Open in Slack
PreviousNext
Powered by