-
Notifications
You must be signed in to change notification settings - Fork 59
need better documentation on doing local runs #162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Nice doc! I'm consistently grinding close to a halt with ivy resolutions. (indeed with the Thanks for suggesting |
Local artifactory helps to speed up resolution for a few reasons:
|
I assume you are right, many thanks. But I can't really fathom why would On Tue, Dec 8, 2015 at 2:57 AM, Grzegorz Kossakowski <
|
Running for 24 hours and going, several restarts required after occasional
And I am very curious why the entire resolution process starts over when rerunning dbuild, it looks like no caching is taking place, or dbuild is invalidating the previous resolution. It would be nice being able to tell it not to invalidate prior resolutions, when doing a rerun. Is this last aspect a pure sbt one? |
@matanster you may find the ivy resolution picture improved now if you tried again — the list of the resolvers in the config file is now much shorter |
or several (comma-separated); improved and documented in #331 |
this is an open-ended ticket, but I'm basically satisfied with the current documentation, so I'm going to go ahead and close it. it isn't documented yet how to specify the Scala nightly you want, but I'll get to that as part of scala/scala-jenkins-infra#189 |
https://github.com/scala/community-builds/wiki was updated today with fresh instructions on this |
Thanks! Sent from my mobile -------- Original Message --------
|
(accumulated random notes on this from the last few months)
though it may not even be worth documenting this better until something is done about the performance issues (its's #152)
I guess setting up local Artifactory helps performance; I haven't tried it yet. there is doc linked from #58
often, running dbuild with
-d
is key in order to see what's going on (I mean if it's the community build itself you're troubleshooting, and not a compiler bug)document how to fix the scala version at a given SHA, to prevent global rebuilds when someone merges a Scala PR? the Jenkins jobs for community builds have a field for this, not sure how it's done locally.
how to run just one project? e.g.
./dbuild-0.9.1/bin/dbuild -n community.dbuild sbinary
works, sort of, but does bypassing the usualscripts/jobs/integrate/community-build
method still get you the right resolvers? need to double check what value the scripts directory script addsalso building just one project doesn't really save you that much time since all projects are still extracted which takes a while. I've been working around this by commenting out big swathes of common.conf and/or community.dbuild
The text was updated successfully, but these errors were encountered: