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

go_proto_library dependency overhaul #1548

Closed
jayconrod opened this Issue Jun 13, 2018 · 1 comment

Comments

Projects
None yet
1 participant
@jayconrod
Contributor

jayconrod commented Jun 13, 2018

Problem

A number of bugs have been reported recently about dependency conflicts when using go_proto_library, especially with gRPC: rules_go #1546, #1530, #1529, #1529, #1385, gazelle #219, #217, #183, #32

There are a couple root causes behind these bugs:

  • go_proto_library rules may depend on go_libraries which were generated from .pb.go files. This sometimes works if the default Go plugin is used, if done consistently. However:
    • If an alternate protoc plugin is used, these files don't get regenerated.
    • We lose information about proto import paths, so the .pb.go files generated by the dependent go_proto_library may have the wrong imports.
    • If a go_proto_library for the same proto is included in the build, it creates compile-, link-, and run-time errors.
  • We provide go_proto_library rules for the Well Known Types in @io_bazel_rules_go//proto/wkt, and Gazelle resolves imports to those rules. Our version of github.com/golang/protobuf, @com_github_golang_protobuf has special aliases for these rules. However, we don't have any special handling for other libraries in github.com/golang/protobuf.
    • Gazelle's special handling and the aliases make it hard to create a pure Go build without proto generation. This may make the build slower than necessary for people who just want to use .pb.go files, and may cause conflicts or unexpected versions if people have vendored these libraries.
    • There are go_libraries implicitly included by the go_grpc plugin. These cause conflicts.
    • There's no canonical proto_library or go_proto_library rules for gRPC or Google APIs. We should have a canonical set of rules for WKTs, gRPC, and Google APIs to avoid conflicts.

Basically, standard dependencies (Well Known Types, gRPC, and Google APIs) are a mess. Libraries are defined in several places (or not at all), and there's no clear, documented example showing how to use them.

Solution summary

  • Declare @com_github_googleapis_googleapis in rules_go go_rules_dependencies(). Define proto_library rules for its contents.
  • Provide go_proto_library and go_library rules for WKTs, gRPC, and Google APIs in @com_github_golang_protobuf and @org_golang_google_genproto. We have existing rules for some of these, and they will stay in their current locations.
  • Remove alias rules in @com_github_golang_protobuf and @org_golang_google_genproto that point to @io_bazel_rules_go//proto/wkt. These were added since the last release and can be rolled back without (officially) breaking compatibility.
  • Make Gazelle resolve Go and proto imports of WKTs, gRPC, and Google APIs to go_proto_library rules defined above.
  • Add a disable_global proto mode to Gazelle to disable special handling of these imports when no go_proto_library dependencies are desired.

Use cases

Pure Go

Pure Go builds do not directly build anything from .proto files. However, they may incorporate go_libraries built from static .pb.go files, and they depend on common proto dependencies (github.com/golang/protobuf/proto, google.golang.org/grpc).
It may be necessary to build existing code this way when migrating to Bazel incrementally since Bazel can't build all .proto files as-is, especially vendored .proto files (vendor prefixes can't be trimmed from include paths in proto_libraries yet). In particular, Kubernetes needs to build this way, at least until bazelbuild/bazel#3867 is implemented.

For these builds, we should provide go_libraries for standard dependencies (WKTs, gRPC, Google APIs) without depending on go_proto_library or the proto compiler.

Pure proto

Developers should be able to generate Go code from .proto files as part of the build without the need to check in .pb.go files. This should work seamlessly for standard dependencies.

We must provide canonical proto_library and go_proto_library rules for all standard dependencies. Gazelle should know how to resolve imports in .proto and .go files to those dependencies.

Hybrid

The two cases above are easiest for support. However, large existing projects won't be able to migrate all at once, especially with dependencies using pure Go. Hybrid builds (with some go_proto_libraries and some static .pb.go files) should work reasonably well.

We may need to impose some restrictions:

  • If any generated proto code is part of the build, when standard dependencies are imported, go_proto_library targets should be used, not go_library. go_proto_library with the default plugin adds standard WKT go_proto_library dependencies implicitly, and these will conflict with the equivalent go_libraries.
  • If an alternate plugin is in use (e.g., gogo), it must generate code compatible with the static .pb.go files.
  • .proto files that correspond to static .pb.go files cannot be imported. We won't be able to map these proto imports to Go imports for those, since we won't know what the .pb.go files were generated from.

Solutions

Rules for standard dependencies

We need to provide proto_library, go_proto_library, and go_library rules for the standard dependencies. The go_library rules should be used in pure Go builds. proto_library and go_proto_library rules should be used in pure proto and mixed builds.

proto_library rules are provided for Well Known Types in @com_google_protobuf (there are already BUILD files here; we don't generate them). There aren't standard proto_library rules for anything else. We should define a repository for github.com/googleapis/googleapis (there's no canonical name; following convention, let's call it @com_github_googleapis_googleapis), and provide proto_library rules using an overlay or a patch.

go_proto_library rules are provided for Well Known Types in @io_bazel_rules_go//proto/wkt. There are aliases for these rules in @com_github_golang_protobuf and @com_github_golang_genproto. It's unclear this is the right place for them. Ideally, go_proto_library rules should be defined alongside their proto_library rules, but we shouldn't rules to @com_google_protobuf. These rules could be defined alongside the static .pb.go files, but that would make it difficult for people to override those repositories. They will probably stay where they are.

We should provide go_proto_library rules for protos in @com_github_googleapis_googleapis. go_repository should be able to generate these correctly, so there's probably no need to check in custom build files.

go_library rules used to be generated for Well Known Types in @com_github_golang_protobuf and @com_github_golang_genproto. These rules were replaced with aliases to go_proto_library rules in @io_bazel_rules_go//proto/wkt, but that change is not released yet and may be rolled back. We should leave these are regular go_library rules generated from .pb.go files so that developers can easily override these repositories with go_repository.

@com_github_golang_genproto also contains go_library rules for gRPC and Google APIs, so no additional work needed there.

Gazelle and go_repository modes

Gazelle should support the use cases described above through modes that can be selected on the command line or through directives in build files.

For pure Go use cases, Gazelle will provide a disable_global proto mode, which will be opt-in. Developers can use disable_global mode by passing -proto=disable on the command line, by writing # gazelle:proto disable in the root build file, or by writing # gazelle:proto disable_global in any build file (only applies in that directory and subdirectories). The former two interfaces already exist; this change adds new meaning. Note that Gazelle currently enters disable mode automatically when visiting a vendor directory; this will not enter disable_global mode.

When in disable_global mode, Gazelle will resolve Go imports of known proto libraries (e.g., github.com/golang/protobuf/ptypes) as if they were regular Go libraries without any custom logic. If they exist in the local repository (e.g., in vendor), those libraries will be used. Gazelle will not generate, update, or delete existing proto_library or go_proto_library rules in pure mode (same as now).

When in the default proto mode or in non-global disable mode (implied by vendor directories), Gazelle may generate, update, and delete proto_library and go_proto_library rules. Gazelle will resolve proto and go imports of standard dependencies to canonical proto_libraries and go_proto_libraries, described above. For example, google/protobuf/any.proto will be resolved to @com_google_protobuf//:any_proto for proto, or @io_bazel_rules_go//proto/wkt:any_go_proto for Go. github.com/golang/protobuf/ptypes/any will also be resolved to @io_bazel_rules_go//proto/wkt:any_go_proto for Go. These special cases will be used instead of any libraries defined in the local repository with the same importpath.

The proto mode of the local repository doesn't affect how go_repository generates build files in external repositories, so in order to use disable_proto mode globally, users will need to set build_extra_args = ["-proto=disable"]. Even though this doesn't affect how repositories are fetched, we may want to promote this argument to a first-class attribute for visibility (like external or build_tags).

Impact to compatibility

  • proto_libraries that import gRPC or Google APIs dependencies from a different location should continue to work. Gazelle will update these dependencies automatically. The location of the WKT proto_libraries is not changing.
  • go_proto_libraries that import WKTs from @com_github_golang_protobuf// will now import go_libraries instead of go_proto_libraries. This was true in the last release; we're rolling back a flawed fix for this. Gazelle has resolved these dependencies to @io_bazel_rules_go//proto/wkt for a while already.
  • go_proto_libraries that import gRPC or Google APIs dependencies from a different location may have conflicts (already true). Gazelle will update these automatically, so there may be some build file churn. The location of WKT go_proto_libraries is not changing.
  • go_proto_libraries that import go_libraries for standard dependencies may have conflicts already. Gazelle will update these automatically, so there may be some build file churn.
  • go_proto_libraries that import other go_libraries for proto dependencies may have conflicts already. Gazelle will fix these when go_proto_libraries are available.
    No changes are being made to the go_proto_library, go_library interfaces.
    Minimal changes are being made to Gazelle. If proto rule generation is already disabled globally, nothing needs to be done to opt into disable_global mode.

Documentation

We should extend proto/core.rst with instructions and examples on how to use and depend on gRPC and Google APIs. We should discuss the following (at least):

  • Differences between pure Go, pure proto, and mixed builds, and why they're important.
  • How to opt into pure Go builds.
  • Locations of standard proto_library, go_proto_library, and go_library rules.
  • Examples of how to use basic protobuf, protobuf with WKTs, basic, gRPC, and Google APIs.
  • How to troubleshoot common issues
  • Conflicts between libraries
  • Can't import vendored proto libraries

Appendix: Proto repositories

Repository URL Bazel name Purpose
github.com/google/protobuf @com_google_protobuf Main proto compiler implementation. Has WKT .proto files. Defines proto_library rules in root package.
github.com/golang/protobuf @com_github_golang_protobuf Go proto plugin. Has WKT .proto and .pb.go files. We define proto_libraries here and aliases to go_proto_libraries defined in //proto/wkt.
google.golang.org/grpc a.k.a. github.com/grpc/grpc-go @org_golang_google_grpc gRPC runtime library, plus several more libraries for handling gRPC types. Does not contain protos or .pb.go.
google.golang.org/genproto a.k.a. github.com/google/go-genproto @org_golang_google_genproto Repository of generated .pb.go files (not .proto) for gRPC and Google APIs. When importing these libraries in Go, canonical paths point here.
github.com/googleapis/googleapis none Repository of .proto files for gRPC and Google Cloud APIs. Does not contain generated files. Has some Bazel files but no proto_library rules.

Appendix: Mapping between proto and Go import paths

Proto import Go import Note
google/* github.com/googleapis/googleapis/google/* gRPC, most other APIs
google/protobuf/*.proto github.com/golang/protobuf/ptypes/* Most WKTs
google/protobuf/api.proto, google/protobuf/field_mask.proto, google/protobuf/source_context.proto google.golang.org/genproto/protobuf/*
google/protobuf/compiler_plugin.proto github.com/golang/protobuf/protoc-gen-go/plugin
google/protobuf/descriptor.proto github.com/golang/protobuf/protoc-gen-go/descriptor
@jayconrod

This comment has been minimized.

Show comment
Hide comment
@jayconrod

jayconrod Jun 15, 2018

Contributor

In addition to supporting the standard plugin, we should also define go_proto_library rules and add support in Gazelle for gogoprotobuf. This support may improve over time, but this issue should not be closed without at least supporting the basic gogo_proto plugin.

Contributor

jayconrod commented Jun 15, 2018

In addition to supporting the standard plugin, we should also define go_proto_library rules and add support in Gazelle for gogoprotobuf. This support may improve over time, but this issue should not be closed without at least supporting the basic gogo_proto plugin.

jayconrod added a commit to jayconrod/rules_go that referenced this issue Jul 2, 2018

Add @go_googleapis in go_rules_dependencies()
@go_googleapis contains proto_library and go_proto_library rules for
github.com/googleapis/googleapis. It's best to have a standard place
for these to avoid conflicts, especially widely used generic protos
like google/rpc/status.proto.

Related bazelbuild#1548

jayconrod added a commit to jayconrod/bazel-gazelle that referenced this issue Jul 2, 2018

Miscelleneous changes before adding new proto modes
* Language.GenerateRules now accepts an otherEmpty parameter, a list
  of empty rules that may be deleted.
* label.Rel can remove the repo name for labels in the same repo.

Related bazelbuild/rules_go#1548

jayconrod added a commit to jayconrod/bazel-gazelle that referenced this issue Jul 2, 2018

Miscelleneous changes before adding new proto modes
* Language.GenerateRules now accepts an otherEmpty parameter, a list
  of empty rules that may be deleted.
* label.Rel can remove the repo name for labels in the same repo.
* Removed dead config.InferProtoMode.

Related bazelbuild/rules_go#1548

jayconrod added a commit to bazelbuild/bazel-gazelle that referenced this issue Jul 2, 2018

Miscelleneous changes before adding new proto modes (#249)
* Language.GenerateRules now accepts an otherEmpty parameter, a list
  of empty rules that may be deleted.
* label.Rel can remove the repo name for labels in the same repo.
* Removed dead config.InferProtoMode.

Related bazelbuild/rules_go#1548

jayconrod added a commit to jayconrod/bazel-gazelle that referenced this issue Jul 2, 2018

internal/language/proto: package mode
The proto extension now supports "package" mode. This can be enabled
with -proto=package on the command line or "# gazelle:proto package"
in a build file. In package mode, multiple proto_libraries will be
generated in a directory. Source files will be grouped by package.

To group source files by an option instead (i.e., option go_package),
the proto extension recognizes the proto_group command line flag and
directive.

The go extension generates go_proto_library rules based on the
proto_library rules generated by the proto extension (independent of
proto mode when possible).

Related bazelbuild/rules_go#1548

jayconrod added a commit to jayconrod/bazel-gazelle that referenced this issue Jul 2, 2018

internal/language/proto: package mode
The proto extension now supports "package" mode. This can be enabled
with -proto=package on the command line or "# gazelle:proto package"
in a build file. In package mode, multiple proto_libraries will be
generated in a directory. Source files will be grouped by package.

To group source files by an option instead (i.e., option go_package),
the proto extension recognizes the proto_group command line flag and
directive.

The go extension generates go_proto_library rules based on the
proto_library rules generated by the proto extension (independent of
proto mode when possible).

Related bazelbuild/rules_go#1548

jayconrod added a commit to jayconrod/bazel-gazelle that referenced this issue Jul 2, 2018

Hard code dependency resolution bindings for @go_googleapis and WKTs
* proto.csv is a table that lists Well Known .proto files and all
  .proto files in @go_googleapis. For each proto import string, it
  lists the proto_library label, the Go import path, and the
  go_proto_library label. This was generated using an ad hoc Python
  script (not included).
* Maps are generated from this file and incorporated into the
  dependency resolution logic in the proto and go extensions.

When bazelbuild#12 is implemented, we can index rules in external repositories,
and we won't need this. We need it for now because there's no clear
correspondence between proto and Go import strings and the libraries
that should be included.

Related bazelbuild/rules_go#1548

jayconrod added a commit to jayconrod/bazel-gazelle that referenced this issue Jul 2, 2018

internal/language/proto: disable_global mode
Similar to disable mode in that no proto_library or go_proto_library
rules will be generated. Additionally, all special cases for WKTs and
Google APIs in the dependency resolution will be disabled. This is
useful for avoiding build-time dependencies on protoc.

Related bazelbuild/rules_go#1548

jayconrod added a commit that referenced this issue Jul 3, 2018

Add @go_googleapis in go_rules_dependencies() (#1581)
@go_googleapis contains proto_library and go_proto_library rules for
github.com/googleapis/googleapis. It's best to have a standard place
for these to avoid conflicts, especially widely used generic protos
like google/rpc/status.proto.

Related #1548

jayconrod added a commit to bazelbuild/bazel-gazelle that referenced this issue Jul 3, 2018

internal/language/proto: package mode (#250)
The proto extension now supports "package" mode. This can be enabled
with -proto=package on the command line or "# gazelle:proto package"
in a build file. In package mode, multiple proto_libraries will be
generated in a directory. Source files will be grouped by package.

To group source files by an option instead (i.e., option go_package),
the proto extension recognizes the proto_group command line flag and
directive.

The go extension generates go_proto_library rules based on the
proto_library rules generated by the proto extension (independent of
proto mode when possible).

Related bazelbuild/rules_go#1548

jayconrod added a commit to jayconrod/bazel-gazelle that referenced this issue Jul 3, 2018

Hard code dependency resolution bindings for @go_googleapis and WKTs
* proto.csv is a table that lists Well Known .proto files and all
  .proto files in @go_googleapis. For each proto import string, it
  lists the proto_library label, the Go import path, and the
  go_proto_library label. This was generated using an ad hoc Python
  script (not included).
* Maps are generated from this file and incorporated into the
  dependency resolution logic in the proto and go extensions.

When bazelbuild#12 is implemented, we can index rules in external repositories,
and we won't need this. We need it for now because there's no clear
correspondence between proto and Go import strings and the libraries
that should be included.

Related bazelbuild/rules_go#1548

jayconrod added a commit to bazelbuild/bazel-gazelle that referenced this issue Jul 3, 2018

Hard code dependency resolution bindings for @go_googleapis and WKTs (#…
…251)

* proto.csv is a table that lists Well Known .proto files and all
  .proto files in @go_googleapis. For each proto import string, it
  lists the proto_library label, the Go import path, and the
  go_proto_library label. This was generated using an ad hoc Python
  script (not included).
* Maps are generated from this file and incorporated into the
  dependency resolution logic in the proto and go extensions.

When #12 is implemented, we can index rules in external repositories,
and we won't need this. We need it for now because there's no clear
correspondence between proto and Go import strings and the libraries
that should be included.

Related bazelbuild/rules_go#1548

jayconrod added a commit to jayconrod/bazel-gazelle that referenced this issue Jul 3, 2018

internal/language/proto: disable_global mode
Similar to disable mode in that no proto_library or go_proto_library
rules will be generated. Additionally, all special cases for WKTs and
Google APIs in the dependency resolution will be disabled. This is
useful for avoiding build-time dependencies on protoc.

Related bazelbuild/rules_go#1548

jayconrod added a commit to bazelbuild/bazel-gazelle that referenced this issue Jul 3, 2018

internal/language/proto: disable_global mode (#252)
Similar to disable mode in that no proto_library or go_proto_library
rules will be generated. Additionally, all special cases for WKTs and
Google APIs in the dependency resolution will be disabled. This is
useful for avoiding build-time dependencies on protoc.

Related bazelbuild/rules_go#1548

pmuetschard added a commit to pmuetschard/gapid that referenced this issue Jul 3, 2018

Update to a new version of go protobuf.
This is the same version that rules_go uses at HEAD. At rules_go HEAD,
we will no longer be able to override the golang protobuf version used,
and so will need to rely on rules_go's version.
This may be fixed with bazelbuild/rules_go#1548.

pmuetschard added a commit to google/gapid that referenced this issue Jul 6, 2018

Update to a new version of go protobuf.
This is the same version that rules_go uses at HEAD. At rules_go HEAD,
we will no longer be able to override the golang protobuf version used,
and so will need to rely on rules_go's version.
This may be fixed with bazelbuild/rules_go#1548.

jayconrod added a commit to jayconrod/rules_go that referenced this issue Aug 6, 2018

jayconrod added a commit to jayconrod/rules_go that referenced this issue Aug 6, 2018

jayconrod added a commit to jayconrod/rules_go that referenced this issue Aug 6, 2018

jayconrod added a commit that referenced this issue Aug 6, 2018

jayconrod added a commit that referenced this issue Aug 22, 2018

Merge branch 'master' into feature/check (#1679)
* Move legacy reproducibility test to new setup (#1585)

* Move legacy reproducibility test to new setup

Also included:
1. Adds an LLVM toolchain to the WORKSPACE file that can be used to
manually test changes against clang on linux.
2. Adds os.PathSeparator to stripped absolute paths to be consistent
with stripping being done everywhere else.
3. Adds a test to check the string "bazel-sandbox" in the binary.
4. Uses the cgo binary instead of a pure binary to check for
reproducibility in the go_test.
5. Tags the target "collect_digests" as manual.

To see how binaries are not reproducible with clang and `-g`, use
```
bazel test --copt=-g --crosstool_top=@llvm_toolchain//:toolchain \
  //tests/reproducibility:go_default_test
```

* remove manual tag from reproducibility test

* Do not use debug mode for reproducibility test.

* Update bazel-toolchain to auto detect OS version

* Add a primitive benchmark (#1599)

bazel_benchmark checks out rules_go to a temporary directory, creates
a temporary workspace, measures the time it takes to build various
targets, then appends the times to a .csv file.

This will probably be much more sophisticated in the future, but it's
good to have something basic now.

* go/tools/bazel_benchmark: extract some logic into bash script (#1601)

bazel_benchmark.sh is now responsible for cloning rules_go at master
into a temp directory. This script can be copied to a bin directory
and run with a timer. The rest of the bazel_benchmark.go logic will
run at the tip of master.

Also: record Bazel version in the output file.

* Set Bazel version tested in Travis CI to 0.15.0 (#1604)

* Speed up downloading of @go_googleapis by using http_archive. (#1603)

The googleapis repository seems to be of such a size that it takes a
long time to clone on a link with lower bandwidth. So long, in fact,
that it causes timeouts in my case.

* Use add_all(), add_joined() instead of deprecated functionality of add() (#1602)

* Change crosstool dependency to @bazel_tools//tools/cpp:current_cc_toolchain (#1605)

//tools/defaults is a special case which is being removed in Bazel.

* Add go_sdk rule and GoSDK provider (#1606)

go_sdk is a new rule that gathers information about an SDK and returns
a GoSDK provider which will get wired into the toolchain.

package_list is a new rule that generates a list of importable
packages from the sources in the SDK (previously, we invoked go list,
which is slower).

* Wire go_sdk and go_toolchain together (#1607)

* go_toolchain has a new mandatory attribute, "sdk", which be
  something that provides GoSDK.
* go_host_sdk, go_local_sdk, and go_download_sdk are now macros that
  wrap the old rules. Each rule declares toolchains in its BUILD.bazel
  file that work on the host architecture. The macro calls
  register_toolchains with these.
* go_register_toolchains no longer calls register_toolchains, but it
  will an SDK rule if "go_sdk" isn't defined. This is a step toward
  allowing multiple SDKs to support multiple execution platforms.
* Action inputs are narrowed to use go.sdk.tools and go.stdlib.libs
  rather than larger sets of files.

* stdlib now uses precompiled libraries if the mode is compatible (#1608)

* Remove deprecated --batch flag (#1617)

* Add go_wrap_sdk rule (#1618)

go_wrap_sdk allows you to configure a Go SDK that was downloaded or
located with another repository rule.

Related #1611

* Optimize args and inputs construction (#1610)

* Use add_all() to lazily construct args

* add_joined() omits the argument if value is an empty list

* Optimize compile

* Optimize cover

* Simplify tags argument construction

* Use any() instead of a dict

* Undo depset() usage

* Statically link tool binaries (#1615)

* A few arguments construction cleanups (#1621)

* Update toolchain and provider documentation [skip ci] (#1622)

* Document race, msan and other attributes for go_binary, go_test [skip ci] (#1624)

* Create .bazelrc (#1626)

* Create .bazelrc

See bazelbuild/bazel#5756 (comment)

* Update .bazelrc

* Remove explicit Label() construction (#1627)

attr.label() converts strings into labels by itself.

* Make go_sdk's package_list optional (#1625)

This will eventually be removed when old versions of Gazelle are no
longer supported and nothing depends on the file by name.

If not provided as an input, go_sdk will generate the file itself.

* Update deprecated single_file -> allow_single_file attribute (#1628)

Also remove allow_files where it conflicts with allow_single_file (not
allowed).
Also remove both allow_files and allow_single_file in private attributes
where executable is set to True (a file cannot be specified anyway -
private attribute).

* Document how to avoid proto conflicts [skip ci] (#1631)

Fixes #1548

* Set RULES_GO_VERSION to 0.14.0 (#1633)

* Propagate mode aspect on "_coverdata" edges (#1632)

* Propagate mode aspect on "_coverdata" edges

This ensures the coverdata library is built in the same mode as the
binary that depends on it.

Fixes #1630

* set pure = "on" on test to make CI happy

* Update dependencies (#1634)

bazel_gazelle to master as of 2018-08-06
com_google_protobuf to v3.6.1
com_github_goog_protobuf to v1.1.1
org_golang_x_net to master as of 2018-08-06
org_golang_google_grpc to v1.14.0
org_golang_google_genproto to master as of 2018-08-06
go_googleapis to master as of 2018-08-06
com_github_kevinburke_go_bindata to v3.11.0
org_golang_x_tools to master as of 2018-08-07

* Announce release 0.14.0 [skip ci] (#1636)

Also, fix gazelle example to use prefix directive instead of
attribute.

* Add CI config to test on RBE. (#1638)

* Add CI config to test on RBE.

* Disable BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN.

This is set by default in the rbe_ubuntu1604 platform, but tests in this
repo need this to be disabled.

* Skip tests that are not RBE compatible.

* Use latest release version of bazel-toolchains repo. (#1639)

* Declare org_golang_x_sys in go_rules_dependencies (#1649)

The newest version of gRPC depends on @org_golang_x_sys. Since we
provide other gRPC dependencies, we should declare this one as well.

Fixes #1648

* Document how to override go_rules_dependencies [skip ci] (#1650)

Related #1649

* Update minimum version of Bazel for Travis CI to 0.16.0 (#1651)

Also, remove logic in .travis.yml for downloading Bazel at HEAD. We're
not doing that anymore.

* Actions that use go.args may now use param files automatically (#1652)

Multiple param files are now supported as well.

* Split go.args into go.builder_args and go.tool_args (#1653)

Both helpers enable multiline files. Any action using either of these
helpers should support them. Other actions may use go.actions.args.

go.builder_args adds default arguments that builders should be able to
interpret, including -sdk and -tags.

go.args is deprecated.

* Use -importcfg files for compiling and linking (#1654)

The Go toolchain has supported importcfg files since 1.9. These files
give the build system finer control over dependencies using importmap
and packagefile declarations. Using these files allows us to abandon
-I and -L flags, which will help us stay under command line length
limits.

Fixes #1637

* Update genproto dependencies (#1657)

* update org_golang_google_genproto

* update go_googleapis

* Add test generates long compile/link command lines (#1655)

Related #1637

* Remove 'cfg = "data"' from all attributes (#1658)

The "data" configuration has been deprecated for a while and has no
effect.

* Remove gazelle and its deps from go_rules_dependencies (#1659)

go_rules_dependencies no longer declares the following repositories:

* bazel_gazelle
* com_github_bazelbuild_buildtools
* com_github_pelletier_go_toml

The "gazelle" rule is removed from //go:def.bzl. It has been
deprecated for some time, and "gazelle fix" replaces it.

* Windows: Use absolute and shortened path for GOROOT environment variable (#1647)

* Update tests ahead of Go 1.11 (#1661)

A test in the old version of org_golang_x_crypto we were testing fails
with Go 1.11. This is fixed in newer versions.

* Remove uses of deprecated dictionary concatenation (#1663)

This removes the need for --incompatible_disallow_dict_plus

* Force absolute paths in builders (#1664)

* Update org_golang_x_tools to master as of 2018-08-15 (#1662)

* Set RULES_GO_VERSION to 0.15.0 (#1665)

* Announce release 0.15.0 [skip ci] (#1666)

* one character fix to README boilerplate [skip ci] (#1667)

* doc: fix grammatical error (#1671)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment