Skip to content
This repository has been archived by the owner on Dec 4, 2023. It is now read-only.

use container based builds on travis #184

Merged
merged 1 commit into from Jul 13, 2015
Merged

use container based builds on travis #184

merged 1 commit into from Jul 13, 2015

Conversation

cowboyd
Copy link
Collaborator

@cowboyd cowboyd commented Jul 10, 2015

@cowboyd
Copy link
Collaborator Author

cowboyd commented Jul 11, 2015

Supposedly, these get more resources, but it actually seemed slower. Of course, it is all highly dependent on time of day

@ignisf
Copy link
Collaborator

ignisf commented Jul 11, 2015

They do start in seconds. I restarted a job to make sure.

@cowboyd
Copy link
Collaborator Author

cowboyd commented Jul 11, 2015

Alrightee, your call then. 🚦

@cowboyd
Copy link
Collaborator Author

cowboyd commented Jul 11, 2015

As a side note, we'd speed things up greatly if we could somehow speed up the checkout of the v8 source. Cloning that entire repo is brutal, but I couldn't find any way to do a shallow clone of a specific branch/tag with the fetch depot tool.

@ignisf
Copy link
Collaborator

ignisf commented Jul 13, 2015

May I just express my opinion of how immensely not invented here the depot_tools are?

@ignisf
Copy link
Collaborator

ignisf commented Jul 13, 2015

https://code.google.com/p/chromium/issues/detail?id=228996 but before you get your hopes up, this does not work for our case -- this checks out always the latest HEAD version and one cannot check out the version we need without defeating the purpose of the shallow clone OR the use of depot_tools

@cowboyd
Copy link
Collaborator Author

cowboyd commented Jul 13, 2015

Even that would be an understatement. It's amazing that no one, at any point was like:

"whoa!..... whoa! guys! .... what are we.... where are we exactly going here with this?"

As someone who dislikes git submodules, I don't see what problem depot_tools solves that submodules don't. Also, they have the advantage of being zero lines of code, as opposed to the hairball swamp of bash and python in which we find ourselves..

Also, I find the book-length goop of python configuration files otherwise known as a GYP configuration an abomination.

@ignisf
Copy link
Collaborator

ignisf commented Jul 13, 2015

So, the only alternative of the 'fetch on every build' routine I've managed to devise is the following strategy:

  1. Remove the .gclient and .gclient_entries files from .gitignore.
  2. Add a submodule for vendor/v8 (yes, again 😢) and check out the version that we need.
  3. Move the fetch invocation to a rake upstream:update task or something similar (this task will delete the .gclient .gclient_entries and v8, fetch the latest v8 and do a git add for the updated files and submodule.
  4. Run just gclient sync --shallow --no-history in vendor/v8 on each build.

@cowboyd
Copy link
Collaborator Author

cowboyd commented Jul 13, 2015

I'd love to see that working, and I'm totally cool giving it a try, but we should do that as a separate, experiment.

@ignisf
Copy link
Collaborator

ignisf commented Jul 13, 2015

👍

cowboyd added a commit that referenced this pull request Jul 13, 2015
use container based builds on travis
@cowboyd cowboyd merged commit c3ad860 into 4.5 Jul 13, 2015
@ignisf ignisf deleted the container-based-travis branch May 13, 2016 00:39
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants