Skip to content
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

Add chrome hostname to CriConnection & eslint fix #2728

Merged
merged 9 commits into from
Aug 14, 2017

Conversation

FrederickGeek8
Copy link
Contributor

@FrederickGeek8 FrederickGeek8 commented Jul 24, 2017

This issue fulfills the request made in issue #2727. This change should allow for Chrome to be located on a hostname other than localhost, as outlined in the issue. It may be noted that I added the hostname parameter to be the second parameter in the constructor so that it does not break any previous implementations of CriConnection.

Additionally, I made a small change that allowed for the yarn tests to be passed. No functionality was changed in this (the second) commit.

Decided to make hostname second parameter to avoid breaking existing
implementations
@FrederickGeek8 FrederickGeek8 changed the title Add chrome hostname to CriConnection Add chrome hostname to CriConnection & eslint fix Jul 24, 2017
@wardpeet
Copy link
Collaborator

TBH I rather have the eslint fix out of this PR but not my call to make.

@FrederickGeek8
Copy link
Contributor Author

FrederickGeek8 commented Jul 24, 2017

Tests weren't compiling without it so I saw it as a necessary fix. I can attempt to remove it if requested however...

const CONNECT_TIMEOUT = 10000;
const DEFAULT_PORT = 9222;

class CriConnection extends Connection {
/**
* @param {number=} port Optional port number. Defaults to 9222;
* @param {string} hostname Optional hostname. Defaults to localhost.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@param {string} should be @param {string=} as we use closure compiler for our minification.

ref: https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler#optional-parameter-in-a-param-annotation

@wardpeet
Copy link
Collaborator

@FrederickGeek8 nonetheless thanks for the PR! 🎉

Lets wait for @paulirish @patrickhulce @brendankenny to pick this review up

@FrederickGeek8
Copy link
Contributor Author

FrederickGeek8 commented Jul 24, 2017

Sorry about that, I thought I put that in. Should be fixed now.

@patrickhulce
Copy link
Collaborator

Awesome thanks so much for jumping on this @FrederickGeek8!

What do you think about plumbing it through to https://github.com/GoogleChrome/lighthouse/blob/master/lighthouse-core/index.js#L38 (read from flags.hostname) as well so the programmatic use case will be covered?

@FrederickGeek8
Copy link
Contributor Author

Like so? Also, do you think that anything should be added to documentation?

@patrickhulce
Copy link
Collaborator

perfect👌 and great question!

Adding this to the CLI will give us the CLI documentation for free (which you can then use to update the copy of the output found in the README).

We don't really have comprehensive documentation of the programmatic flags yet, but you could add a nod to setting flags.host over in the first example in using programmatically docs for now.

@FrederickGeek8
Copy link
Contributor Author

I added some documentation to the mentioned locations. I also fixed the PR conflict.

@paulirish
Copy link
Member

Presumably this does indeed work? I had thought the remote-debugging-port was only listening for localhost connections. Was there another CLI flag you needed to pass to relax that, or am i wrong?

@patrickhulce
Copy link
Collaborator

Presumably this does indeed work? I had thought the remote-debugging-port was only listening for localhost connections. Was there another CLI flag you needed to pass to relax that, or am i wrong?

Maybe there's a special way docker works its magic for networking containers together? I seem to remember it having something unique going on.

@brendankenny
Copy link
Member

Sounds plausible. @FrederickGeek8 or @salvocanna can you comment to clarify your use case/workflow?

@salvocanna
Copy link

salvocanna commented Aug 1, 2017

@paulirish indeed, I'm using yukinying/chrome-headless-browser-docker and this line forces the bind to 0.0.0.0 so allowing external connections.

I'm using one docker container with the full application in node (lighthouse included) and another container to host the actual browser. Seems to work fine updating the hostname.

docs/readme.md Outdated
@@ -13,6 +13,7 @@ const chromeLauncher = require('lighthouse/chrome-launcher');

function launchChromeAndRunLighthouse(url, flags = {}, config = null) {
return chromeLauncher.launch().then(chrome => {
flags.host = 'localhost';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should actually remove this, sorry :) We don't document any of the other possible flags here, and we want to keep this example as simple as possible for copy/pasting to get started.

We should start a separate section to document the flags (or at least point to the CLI flags as the same as what this accepts), but that's a change for a different PR.

logLevel: string
port: number, host: string, chromeFlags: string, output: any, outputPath: string,
interactive: boolean, saveArtifacts: boolean, saveAssets: boolean, view: boolean,
maxWaitForLoad: number, logLevel: string
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the diff would be a lot clearer (just adding host: string) if this had just been appended on the end here, but no biggie :)

@@ -116,7 +116,9 @@ class GithubApi {
const filename = Object.keys(json.files)
.find(filename => filename.endsWith(GithubApi.LH_JSON_EXT));
if (!filename) {
throw new Error(`Failed to find a Lighthouse report (*${GithubApi.LH_JSON_EXT}) in gist ${id}`);
throw new Error(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

drop this change from the PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was to fix a conflict that was introduced from a different PR somewhere along the road.

* @constructor
*/
constructor(port) {
constructor(port, hostname) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is an older file, so it doesn't use them yet, but do you want to switch these two to use default parameters instead of ||?

Slight difference in port since it won't turn 0 into 9222, but we don't support port 0 at this stage anyways (trying to find a debugger on a random port makes no sense)

@@ -77,6 +77,7 @@ export function getFlags(manualArgv?: string) {
CHROME_PATH: Explicit path of intended Chrome binary. If set must point to an executable of a build of Chromium version 54.0 or later. By default, any detected Chrome Canary or Chrome (stable) will be launched.
`,
'perf': 'Use a performance-test-only configuration',
'host': 'The host to use for the debugging protocol.',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should copy this to https://github.com/GoogleChrome/lighthouse/blob/master/readme.md#cli-options, too (like #2757 just did for CHROME_PATH)

Also remove comments from docs/readme.md, add comment to readme.md, and
make cli-flags.ts change more digestible.
* @constructor
*/
constructor(port) {
constructor(port = DEFAULT_PORT, hostname = DEFAULT_HOSTNAME) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these still need to be saved on this.port and this.hostname (cause of the test failures)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad...

@FrederickGeek8
Copy link
Contributor Author

@brendankenny Just a heads up, I made the requested changes.

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry for being slow; thanks for the ping. LGTM!

@googlebot
Copy link

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that they're okay with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

@paulirish paulirish merged commit 0455283 into GoogleChrome:master Aug 14, 2017
@paulirish
Copy link
Member

I renamed host to hostname everywhere, but this is now landed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants