building rules_webtesting for go tooling seems busted

[jmhodges]

I've getting errors when trying to build any go target including go_web_test_suite when I call the rules_webtesting *_repositories functions in my WORKSPACE.

The errors I get are

ERROR: /private/var/tmp/_bazel_jmhodges/ee957dabdee1b1a9e1f2fe90369cf80f/external/io_bazel_rules_webtesting/web/repositories.bzl:146:3: //external:com_github_gorilla_mux: no such attribute 'url' in 'go_repository' rule.
ERROR: /private/var/tmp/_bazel_jmhodges/ee957dabdee1b1a9e1f2fe90369cf80f/external/io_bazel_rules_webtesting/web/repositories.bzl:157:3: //external:com_github_tebeka_selenium: no such attribute 'url' in 'go_repository' rule.
ERROR: error loading package '': Encountered error while reading extension file 'package_manager/package_manager.bzl': no such package '@distroless//package_manager': error loading package 'external': Could not load //external package.

In my WORKSPACE is:

load("@io_bazel_rules_webtesting//web:repositories.bzl",
    "browser_repositories",
    "web_test_repositories")

web_test_repositories()

browser_repositories(
    chromium = True,
)

and

git_repository(
    name = "io_bazel_rules_go",
    remote = "https://github.com/bazelbuild/rules_go.git",
    commit = "072a319be76f2c20b10c5c8b6f8cb8f3508f8196",
)

load("@io_bazel_rules_go//go:def.bzl", "go_repositories", "new_go_repository")

As soon as I comment out the web_test_repositories and browser_repositories lines, all of my Go targets (that are not rules_webtesting ones, of course) work again.

Both of the rules_* repos above are set to the current HEAD of their respective git repos. The current HEAD of rules_go I also tried this with tag = 0.5.0 for the rules_go repo and got the same errors but that's to be expected as that version had not yet combined new_go_repository with go_repository. I'm on bazel 0.5.1 on OS X.

(I suspect the rules_go external that rules_webtesting defines is either incorrect or colliding with the ones defined in my own WORKSPACE somehow but this is all very strange to me.)

[jmhodges]

(Also, I tried a bazel clean --expunge and it seemed to do nothing to fix the problem.)

[jmhodges]

I got some distance on this but go_web_test_suite now breaks at run time with:

ERROR: /Users/jmhodges/founding/src/founding/go/svc/howsmyssl-billing/integration/BUILD.bazel:3:1: in web_test rule //go/svc/howsmyssl-billing/integration:integration_chromium-native: 
Traceback (most recent call last):
    File "/Users/jmhodges/founding/src/founding/go/svc/howsmyssl-billing/integration/BUILD.bazel", line 3
        web_test(name = 'integration_chromium-native')
    File "/private/var/tmp/_bazel_jmhodges/ee957dabdee1b1a9e1f2fe90369cf80f/external/io_bazel_rules_webtesting/web/internal/web_test.bzl", line 51, in _web_test_impl
        fail("Browser {browser} requires tags...))
Browser @io_bazel_rules_webtesting//browsers:chromium-native requires tags ["noci"] that are missing.

I posted a PR at https://github.com/bazelbuild/rules_webtesting/issues/148

[jmhodges]

(That last error seems to be a problem with the chromium-native target given in the README)

[jmhodges]

Well, that PR gets me all the way to this problem on MacOS 10.12.5:

2017/06/28 19:30:32 launching HTTP server at: JeffsPersonalMBP:63762
Starting ChromeDriver 2.29.461585 (0be2cd95f834e9ee7c46bcc7cf405b483f5ae83b) on port 63757
Only local connections are allowed.
2017/06/28 19:30:33 [WebDriver proxy]: context deadline exceeded waiting for healthy: [WebDriver proxy]: error getting http://JeffsPersonalMBP:63762/healthz: Get http://JeffsPersonalMBP:63762/healthz: dial tcp: lookup JeffsPersonalMBP: no such host

This seems to be a bug in the expectations in httphelper.FQDN. I'm not sure why we would want that to return the hostname if the LookupHost on it fails, but I do see that it was explicitly written to do so.

[jmhodges]

It seems that my hostname is JeffsPersonalMBP but in the Sharing section of my Mac OS System Preferences, the domain it talks about is Jeffs-Personal-MacBook-Pro.local

So, that's fun.

Is the attempt here to boot up in such a way that we get a open-to-the-network interface to the proxy? If so, why do we want to do that? (Just curious, not furious!)

[joshbruning]

The code was authored to support: 1) local execution on Linux w/ browser running on Linux 2) local execution on Linux w/ browser running in a Windows VM 3) remote execution on various Linux servers

"localhost" worked for 1; os.hostname worked for 1 & 2; all that extra logic was added to support 3 as for our servers, os.hostname wasn't returning FQDN (for local executions, it was); I don't believe that throwing out os.hostname in favor of "localhost" would cause any issues for our VM stuff as I believe all that extra logic works fine on our Linux workstations ... but I'd have to check.

So that's the history; we really haven't spent much effort yet looking into environments that we don't use ourselves.

[jmhodges]

Totally fair!

[joshbruning]

I believe there isn't anything else to do here at the moment; thanks for updating the version! Perhaps we should establish a process to do this periodically.