Issues with Devtools being dependent on specific serve_rev and Webkit Head commits.

[Sagar Dhawan]

Posted on Blink-dev previously. https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/PnULXkdIRqU

So I've been trying to resolve a couple of issues(unrelated to each other) I have with devtools. 

1. M42 Head commit dependency (404 Resource not found)
1. In M42, lastchange.py was updated to look at the head commit in third_party/Webkit to update LASTCHANGE.blink with the blink revision.
2. On non git-svn projects where the top commit won't necessarily have a valid git-svn-id, the script puts the full commit hash into LASTCHANGE.blink. The url this generates is an invalid devtools url. like (serve_rev/@{fullCommitHashHere}/devtools.html)
3. As a work around I've updated lastchange.py to do what it used to before(Why was this changed?), i.e, grep the entire git log in Webkit for a git-svn-id. This way it uses the first valid commit it finds.
4. I feel as if this scenario was not anticipated. Custom commits being on top in Webkit on m42 and beyond will end up with broken devtools (chrome://inspect specifically).
2. Devtools urls not being hosted consistently (White screens because "JS error- DevToolssHost is not defined and "source*.css/js/html files are not being served)
1. Sometimes, even with a valid devtools url, devtools can be broken if the serve_rev isn't hosting all the files. 
2. Example urls - working and broken - Note the different ids in the url and the Js console error on the broken url.
3. Further inspection of both urls (F12->sources) shows that all the backend files are being served but the frontend(source*) css/html/js files are not. So we're stuck with a white page.
4. Is this normal? Why are some revisions not being hosted correctly? What am I expected to do besides disabling dynamic LASTCHANGE.blink population?

After the discussion on Blink Dev, it appears that for issue 2 - There might be a bug in the the chrome devtools front end appspot server for revision@187429. (JS error - DevToolsHost is not defined causes a white screen). Is it possible for devs to fix the files hosted at that revision or should I be updating to a different one?

As for Issue 1 - I think this might an unforeseen issue caused by updates to the way lastchange.py works and thought I should bring it to your attention.

Finally, what is the expected lifetime of a revision? Does every revision stay alive "forever" or are older revisions deprecated after a branch is complete?

[Paul Irish]

Can't answer all your questions, but I'll try a few…

On Wed, Mar 18, 2015 at 2:33 PM, Sagar Dhawan <dhawan...@gmail.com> wrote:

After the discussion on Blink Dev, it appears that for issue 2 - There might be a bug in the the chrome devtools front end appspot server for revision@187429. (JS error - DevToolsHost is not defined causes a white screen). Is it possible for devs to fix the files hosted at that revision or should I be updating to a different one?

From what it looks like, this is for m40 or so.  That's not a supported Chrome version so I don't think we'd update it if it had a bug.

But beyond that, we don't have a means to update hosted files after they've been published. Everything up there is snapshotted and never touched.

 

Finally, what is the expected lifetime of a revision? Does every revision stay alive "forever" or are older revisions deprecated after a branch is complete?

We have no plans to let any existing frontend URL 404. So they'll stay alive forever yes.

[Sagar Dhawan]

Thanks, that addresses most of my questions. 

Since the urls won't get taken down intentionally, we'll just use a fixed devtools revision instead of having it generated on every build.

Will wait on hearing from someone in Dev about the change to lastchange.py breaking devtools when the top commit doesn't have a git-svn-id. 
I've already patched it to grep the whole log. I think you guys should revert to that as well. I don't know why a decision was made to search only the HEAD.