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.

Sign up for GitHub

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

Jump to bottom

building rules_webtesting for go tooling seems busted #147

Closed
jmhodges opened this issue Jun 29, 2017 · 8 comments
Closed

building rules_webtesting for go tooling seems busted #147

jmhodges opened this issue Jun 29, 2017 · 8 comments

Comments

@jmhodges
Copy link
Contributor

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
Copy link
Contributor Author

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

jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Jun 29, 2017
@jmhodges
fix build errors with latest rules_go
a2c36c7 
Recent rules_go versions do not have a `url` parameter on `go_repository`, so
rules_webtesting, unfortunately, has to be changed.

This patch also upgrades the rules_go external in this WORKSPACE to its current
HEAD.

Fixes bazelbuild#147
jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Jun 29, 2017
@jmhodges
fix build errors with latest rules_go
baf891d 
Recent rules_go versions do not have a `url` parameter on `go_repository`, so
rules_webtesting, unfortunately, has to be changed.

There is also a new requirement that if a `urls` parameter is specified, than a
`tag` parameter may not be. So, we fix up the gorilla mux dep.

This patch also upgrades the rules_go external in this WORKSPACE to its current
HEAD.

Finally, it corrects the README's Go example as `go_test`'s `deps` parameter now
rejects targets that are not go_library or similar targets.

This does not address the noci tag problem discussed in bazelbuild#147.

Updates bazelbuild#147
@jmhodges jmhodges mentioned this issue Jun 29, 2017
Merged
@jmhodges
Copy link
Contributor Author

jmhodges commented Jun 29, 2017 •
edited

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 #148

jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Jun 29, 2017
@jmhodges
fix build errors with latest rules_go
b3b64a6 
Recent rules_go versions do not have a `url` parameter on `go_repository`, so
rules_webtesting, unfortunately, has to be changed.

There is also a new requirement that if a `urls` parameter is specified, than a
`tag` parameter may not be. So, we fix up the gorilla mux dep.

This patch also upgrades the rules_go external in this WORKSPACE to its current
HEAD.

This does not address the noci tag problem discussed in bazelbuild#147.

Updates bazelbuild#147
@jmhodges
Copy link
Contributor Author

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

jmhodges added a commit to jmhodges/rules_webtesting that referenced this issue Jun 29, 2017
@jmhodges
fix build errors with latest rules_go
e912423 
Recent rules_go versions do not have a `url` parameter on `go_repository`, so
rules_webtesting, unfortunately, has to be changed.

There is also a new requirement that if a `urls` parameter is specified, than a
`tag` or `commit` parameter may not be. So, we fix up the gorilla/mux and
selenium deps.

This patch also upgrades the rules_go external in this WORKSPACE to its current
HEAD.

This does not address the noci tag problem discussed in bazelbuild#147.

Updates bazelbuild#147
@jmhodges
Copy link
Contributor Author

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.

joshbruning pushed a commit that referenced this issue Jun 29, 2017
@jmhodges @joshbruning
fix build errors with latest rules_go (#148)
12613b4 
Recent rules_go versions do not have a `url` parameter on `go_repository`, so
rules_webtesting, unfortunately, has to be changed.

There is also a new requirement that if a `urls` parameter is specified, than a
`tag` or `commit` parameter may not be. So, we fix up the gorilla/mux and
selenium deps.

This patch also upgrades the rules_go external in this WORKSPACE to its current
HEAD.

This does not address the noci tag problem discussed in #147.

Updates #147
@jmhodges
Copy link
Contributor Author

jmhodges commented Jun 29, 2017 •
edited

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!)

@jmhodges jmhodges mentioned this issue Jun 29, 2017
Closed
@joshbruning
Copy link
Collaborator

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
Copy link
Contributor Author

Totally fair!

@joshbruning
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jmhodges @joshbruning