-
Notifications
You must be signed in to change notification settings - Fork 166
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
Host icu downloads locally (icu download is breaking) #190
Comments
The simple fix I have in mind is to put the .zip in a specific place on the build machines (/home/iojs/icu4c-55_1-src.zip would work for everything non-Windows as it stands now) and do a /cc @nodejs/intl |
I have a patch adding a download-path to configure. Good enough? |
can you use that to point to a directory and it'll check if the .zip is in that directory? that'd be perfect because it'd solve for the case where we don't have the .zip in place or it's not the right version. |
Yep. I'd also like to switch to curl/wget. On windows curl is aliased to |
this is getting out of hand, the OSX release slaves have been dying part way through ICU download, latest incarnation was
|
FYI, @srl295 and I have been pondering whether it would be feasible to just host it in git. Not much progress on that investigation, but it's on our plate. |
@orangemocha as in, bundle in |
Ahh, let me see if I can get the sourceforge mirror to work again. There's an issue somewhere to have a backup URL. |
@jbergstroem ICU 54 and 55 are now redirects to sourceforge CDN, please let me know if this helps. |
You can already do that! edit also it will check if its |
The "use backup URLs" issue is now nodejs/node#2746 |
That's what I'm after! I'm going to hook this up to some of the Ci machines and get them to do a |
Perfect. El martes, 8 de septiembre de 2015, Rod Vagg notifications@github.com
|
We really need to do something about this folks, it holds up every release now, it's been a huge frustration to both @Fishrock123 and I for each release we've pushed through, many many start/stop cycles and the problems with the Windows linker hanging for minutes and causing the next build to fail if you start it too soon only exacerbates the problem. If I need to take some action please let me know, I'm unsure what the state of this is. See https://ci.nodejs.org/job/iojs+release/nodes=win2008r2-release-ia32/192/console for the latest drama, happens most frequently on Windows. |
Same error, persistent on both Windows boxes, I need to get v4.1.2 out today as announced for fixing the DoS bug and I can't get past this. Halp! @nodejs/intl @nodejs/build |
Cleaned out workspaces, emptied trash and rebooted those machines and they both suddenly work again, perhaps this is a temporary workaround, a pretty terrible one but it's something. |
Rod, thought this was solved. Let's chat about this as soon as possible. |
This will improve matters once it lands: nodejs/node#3200 - if we land this one before ICU 56 is landed, then manually caching ICU-54 and ICU-55 on the buildslaves will be sufficient. |
I believe we're now hosting these on all release-machines. We should improve our ansible-stack by downloading these as part of the setup, though. |
All windows test machines have this now.
|
@joaocgreis these are only relevant for release machines (for now) |
We've seen quite a bit of these through the buildbots:
There's a few routes to explore here to improve the actual download; but one thing we can do from an infra point of view could be setting up a proxy_store location match on our local nginx that would pull files from
icu-project.org
and then allow us to use our cdn to cache it. Thoughts?The text was updated successfully, but these errors were encountered: