Work around getrlimit syscall error on darwin

[jeremyschlatter]

Fixes #285

[achew22]

Thanks for sending in a PR to fix the issue!

[jeremyschlatter]

@achew22 Could you cut a release here? I'd love to get this change into the homebrew formula.

[achew22]

@jeremyschlatter, working on this. Sorry it's taking so long. There is an incompatibility between rules_go and the way I build the multi platform binaries that I haven't run in a while so I have to figure out what's going on.

[achew22]

I'm just going to live-blog this. Something about skylib and rules_go is not interacting well together

Traceback (most recent call last):
        File "/home/achew22/.cache/bazel/_bazel_achew22/378856566cc5ab2d8fea39cb4a335e93/external/io_bazel_rules_go/go/tools/coverdata/BUILD.bazel", line 3
                go_tool_library(name = 'coverdata')
        File "/home/achew22/.cache/bazel/_bazel_achew22/378856566cc5ab2d8fea39cb4a335e93/external/io_bazel_rules_go/go/private/rules/library.bzl", line 42, in _go_library_impl
                go.archive(go, source)
        File "/home/achew22/.cache/bazel/_bazel_achew22/378856566cc5ab2d8fea39cb4a335e93/external/io_bazel_rules_go/go/private/actions/archive.bzl", line 219, in go.archive
                sets.union(cgo_exports, *[a.cgo_exports for a...])
        File "/home/achew22/.cache/bazel/_bazel_achew22/378856566cc5ab2d8fea39cb4a335e93/external/bazel_skylib/lib/new_sets.bzl", line 184, in sets.union
                struct(_values = dicts.add(*[s._values ...]))
        File "/home/achew22/.cache/bazel/_bazel_achew22/378856566cc5ab2d8fea39cb4a335e93/external/bazel_skylib/lib/new_sets.bzl", line 184, in struct
                dicts.add(*[s._values for s in args])
        File "/home/achew22/.cache/bazel/_bazel_achew22/378856566cc5ab2d8fea39cb4a335e93/external/bazel_skylib/lib/new_sets.bzl", line 184, in dicts.add
                s._values

[achew22]

I'm invoking using bazelisk which reports

$ bazelisk version
Bazelisk version: development
Build label: 0.29.1
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Sep 10 13:44:39 2019 (1568123079)
Build timestamp: 1568123079
Build timestamp as int: 1568123079

[achew22]

Seems recent enough. I moved loading rules_go to the top of the WORKSPACE and that seems to have fixed things.

Now when I build the npm package.json I get

     "version": "{STABLE_GIT_VERSION}",

as the version, which I think means it is stamping but the value isn't being loaded correctly?

[achew22]

Adding an assert to validate that demonstrates that yes, there is something weird there. I now get the panic

panic: The version string was not expanded. Got: {STABLE_GIT_VERSION}

I wonder what's up with that

[achew22]

I suspect it is related to this PR in rules_go

This was intentionally a user-facing change. We were not being consistent with other languages.

Makes sense... but I think I'm setting the --stamp flag

[achew22]

Rebuilding with bazelisk build -s --config=release //release/npm:package.json and inspecting the output confirms the stamp value is not getting replaced.

Output:

  bazel-out/host/bin/external/go_sdk/builder link -sdk external/go_sdk -installsuffix linux_amd64 -package_list bazel-out/host/bin/external/go_sdk/packages.txt -X 'main.Version={STABLE_GIT_VERSION}' -o bazel-out/host/bin/release/npm/linux_amd64_stripped/npm -main bazel-out/host/bin/release/npm/linux_amd64_stripped/npm%/github.com/bazelbuild/bazel-watcher/npm.a -p github.com/bazelbuild/bazel-watcher/npm -- -extld /usr/bin/gcc '-buildid=redacted' -w -extldflags '-fuse-ld=gold -Wl,-no-as-needed -Wl,-z,relro,-z,now -B/usr/bin -pass-exit-codes -lm'

[achew22]

Being more explicit gets similar results:

bazelisk build -s --stamp --workspace_status_command="python tools/workplace_status.py" --config=release //release/npm:package.json

Linker invocation:

  bazel-out/host/bin/external/go_sdk/builder link -sdk external/go_sdk -installsuffix linux_amd64 -package_list bazel-out/host/bin/external/go_sdk/packages.txt -X 'main.Version={STABLE_GIT_VERSION}' -o bazel-out/host/bin/release/npm/linux_amd64_stripped/npm -main bazel-out/host/bin/release/npm/linux_amd64_stripped/npm%/github.com/bazelbuild/bazel-watcher/npm.a -p github.com/bazelbuild/bazel-watcher/npm -- -extld /usr/bin/gcc '-buildid=redacted' -w -extldflags '-fuse-ld=gold -Wl,-no-as-needed -Wl,-z,relro,-z,now -B/usr/bin -pass-exit-codes -lm')

Huh...

-X 'main.Version={STABLE_GIT_VERSION}' is the interesting part

[achew22]

Filed bazel-contrib/rules_go#2224 with rules_go. Let's see what I did wrong there. Unfortunately I don't have more than an hour to work on this today. Will pick up when there is action on that bug.

[jeremyschlatter]

Thanks for the updates, @achew22