Go rules for Bazel

Go rules for Bazel

Mailing list: bazel-go-discuss

Slack: #go on Bazel Slack, #bazel on Go Slack

Announcements

2021-10-06
Release v0.29.0 is now available. This enables nogo analyzers to depend on go_library rules, removes the rules_cc dependency, adds automatic target detection to gopackagesdriver, and fixes some cgo-related bugs. See the release notes for details.
2021-07-07
Release v0.28.0 is now available. This adds experimental editor support, plus a few other changes. See the release notes for details. Thanks to all who contributed!
2021-03-18
Release v0.27.0 is now available. This updates org_golang_x_tools and adds org_golang_x_sys. This should have been done in v0.26.0. Additionally, v0.24.14 is now available with support for Go 1.16.2, 1.16.1, 1.15.10, and 1.15.9. This will be the last release on the 0.24 branch. 0.27 and 0.25 are now the two supported branches.
2021-03-08
Release v0.26.0 is now available. This provides support for the new //go:embed attribute, plus several other improvements. Gazelle v0.23.0 is also available with support for embedsrcs attributes (needed for //go:embed) and a few other improvements.

Contents

Documentation

Quick links

Overview

The rules are in the beta stage of development. They support:

They currently do not support or have limited support for:

The Go rules are tested and supported on the following host platforms:

  • Linux, macOS, Windows
  • amd64

Users have reported success on several other platforms, but the rules are only tested on those listed above.

Note: The latest version of these rules (v0.28.0) requires Bazel ≥ 4.0.0 to work.

The master branch is only guaranteed to work with the latest version of Bazel.

Setup

System setup

To build Go code with Bazel, you will need:

  • A recent version of Bazel.
  • A C/C++ toolchain (if using cgo). Bazel will attempt to configure the toolchain automatically.
  • Bash, patch, cat, and a handful of other Unix tools in PATH.

You normally won't need a Go toolchain installed. Bazel will download one.

See Using rules_go on Windows for Windows-specific setup instructions. Several additional tools need to be installed and configured.

Initial project setup

Create a file at the top of your repository named WORKSPACE, and add the snippet below (or add to your existing WORKSPACE). This tells Bazel to fetch rules_go and its dependencies. Bazel will download a recent supported Go toolchain and register it for use.

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "io_bazel_rules_go",
    sha256 = "2b1641428dff9018f9e85c0384f03ec6c10660d935b750e3fa1492a281a53b0f",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.29.0/rules_go-v0.29.0.zip",
        "https://github.com/bazelbuild/rules_go/releases/download/v0.29.0/rules_go-v0.29.0.zip",
    ],
)

load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")

go_rules_dependencies()

go_register_toolchains(version = "1.17.1")

You can use rules_go at master by using git_repository instead of http_archive and pointing to a recent commit.

Add a file named BUILD.bazel in the root directory of your project. You'll need a build file in each directory with Go code, but you'll also need one in the root directory, even if your project doesn't have Go code there. For a "Hello, world" binary, the file should look like this:

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

go_binary(
    name = "hello",
    srcs = ["hello.go"],
)

You can build this target with bazel build //:hello.

Generating build files

If your project can be built with go build, you can generate and update your build files automatically using gazelle.

Add the bazel_gazelle repository and its dependencies to your WORKSPACE. It should look like this:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "io_bazel_rules_go",
    sha256 = "8e968b5fcea1d2d64071872b12737bbb5514524ee5f0a4f54f5920266c261acb",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.28.0/rules_go-v0.28.0.zip",
        "https://github.com/bazelbuild/rules_go/releases/download/v0.28.0/rules_go-v0.28.0.zip",
    ],
)

http_archive(
    name = "bazel_gazelle",
    sha256 = "de69a09dc70417580aabf20a28619bb3ef60d038470c7cf8442fafcf627c21cb",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/bazel-gazelle/releases/download/v0.24.0/bazel-gazelle-v0.24.0.tar.gz",
        "https://github.com/bazelbuild/bazel-gazelle/releases/download/v0.24.0/bazel-gazelle-v0.24.0.tar.gz",
    ],
)

load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")
load("@bazel_gazelle//:deps.bzl", "gazelle_dependencies")

go_rules_dependencies()

go_register_toolchains(version = "1.17.2")

gazelle_dependencies()

Add the code below to the BUILD.bazel file in your project's root directory. Replace the string after prefix with an import path prefix that matches your project. It should be the same as your module path, if you have a go.mod file.

load("@bazel_gazelle//:def.bzl", "gazelle")

# gazelle:prefix github.com/example/project
gazelle(name = "gazelle")

This declares a gazelle binary rule, which you can run using the command below:

bazel run //:gazelle

This will generate a BUILD.bazel file with go_library, go_binary, and go_test targets for each package in your project. You can run the same command in the future to update existing build files with new source files, dependencies, and options.

Writing build files by hand

If your project doesn't follow go build conventions or you prefer not to use gazelle, you can write build files by hand.

In each directory that contains Go code, create a file named BUILD.bazel Add a load statement at the top of the file for the rules you use.

load("@io_bazel_rules_go//go:def.bzl", "go_binary", "go_library", "go_test")

For each library, add a go_library rule like the one below. Source files are listed in the srcs attribute. Imported packages outside the standard library are listed in the deps attribute using Bazel labels that refer to corresponding go_library rules. The library's import path must be specified with the importpath attribute.

go_library(
    name = "foo_library",
    srcs = [
        "a.go",
        "b.go",
    ],
    importpath = "github.com/example/project/foo",
    deps = [
        "//tools",
        "@org_golang_x_utils//stuff",
    ],
    visibility = ["//visibility:public"],
)

For tests, add a go_test rule like the one below. The library being tested should be listed in an embed attribute.

go_test(
    name = "foo_test",
    srcs = [
        "a_test.go",
        "b_test.go",
    ],
    embed = [":foo_lib"],
    deps = [
        "//testtools",
        "@org_golang_x_utils//morestuff",
    ],
)

For binaries, add a go_binary rule like the one below.

go_binary(
    name = "foo",
    srcs = ["main.go"],
)

Adding external repositories

For each Go repository, add a go_repository rule to WORKSPACE like the one below. This rule comes from the Gazelle repository, so you will need to load it. gazelle update-repos can generate or update these rules automatically from a go.mod or Gopkg.lock file.

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

# Download the Go rules.
http_archive(
    name = "io_bazel_rules_go",
    sha256 = "2b1641428dff9018f9e85c0384f03ec6c10660d935b750e3fa1492a281a53b0f",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.29.0/rules_go-v0.29.0.zip",
        "https://github.com/bazelbuild/rules_go/releases/download/v0.29.0/rules_go-v0.29.0.zip",
    ],
)

# Download Gazelle.
http_archive(
    name = "bazel_gazelle",
    sha256 = "de69a09dc70417580aabf20a28619bb3ef60d038470c7cf8442fafcf627c21cb",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/bazel-gazelle/releases/download/v0.24.0/bazel-gazelle-v0.24.0.tar.gz",
        "https://github.com/bazelbuild/bazel-gazelle/releases/download/v0.24.0/bazel-gazelle-v0.24.0.tar.gz",
    ],
)

# Load macros and repository rules.
load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")
load("@bazel_gazelle//:deps.bzl", "gazelle_dependencies", "go_repository")

# Declare Go direct dependencies.
go_repository(
    name = "org_golang_x_net",
    importpath = "golang.org/x/net",
    sum = "h1:zK/HqS5bZxDptfPJNq8v7vJfXtkU7r9TLIoSr1bXaP4=",
    version = "v0.0.0-20200813134508-3edf25e44fcc",
)

# Declare indirect dependencies and register toolchains.
go_rules_dependencies()

go_register_toolchains(version = "1.17")

gazelle_dependencies()

protobuf and gRPC

To generate code from protocol buffers, you'll need to add a dependency on com_google_protobuf to your WORKSPACE.

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "com_google_protobuf",
    sha256 = "d0f5f605d0d656007ce6c8b5a82df3037e1d8fe8b121ed42e536f569dec16113",
    strip_prefix = "protobuf-3.14.0",
    urls = [
        "https://mirror.bazel.build/github.com/protocolbuffers/protobuf/archive/v3.14.0.tar.gz",
        "https://github.com/protocolbuffers/protobuf/archive/v3.14.0.tar.gz",
    ],
)

load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")

protobuf_deps()

You'll need a C/C++ toolchain registered for the execution platform (the platform where Bazel runs actions) to build protoc.

The proto_library rule is provided by the rules_proto repository. protoc-gen-go, the Go proto compiler plugin, is provided by the com_github_golang_protobuf repository. Both are declared by go_rules_dependencies. You won't need to declare an explicit dependency unless you specifically want to use a different version. See Overriding dependencies for instructions on using a different version.

gRPC dependencies are not declared by default (there are too many). You can declare them in WORKSPACE using go_repository. You may want to use gazelle update-repos to import them from go.mod.

See Proto dependencies, gRPC dependencies for more information. See also Avoiding conflicts.

Once all dependencies have been registered, you can declare proto_library and go_proto_library rules to generate and compile Go code from .proto files.

load("@rules_proto//proto:defs.bzl", "proto_library")
load("@io_bazel_rules_go//proto:def.bzl", "go_proto_library")

proto_library(
    name = "foo_proto",
    srcs = ["foo.proto"],
    deps = ["//bar:bar_proto"],
    visibility = ["//visibility:public"],
)

go_proto_library(
    name = "foo_go_proto",
    importpath = "github.com/example/protos/foo_proto",
    protos = [":foo_proto"],
    visibility = ["//visibility:public"],
)

A go_proto_library target may be imported and depended on like a normal go_library.

Note that recent versions of rules_go support both APIv1 (github.com/golang/protobuf) and APIv2 (google.golang.org/protobuf). By default, code is generated with github.com/golang/protobuf/cmd/protoc-gen-gen for compatibility with both interfaces. Client code may import use either runtime library or both.

FAQ

Go

Protocol buffers

Dependencies and testing

Can I still use the go command?

Yes, but not directly.

rules_go invokes the Go compiler and linker directly, based on the targets described with go_binary and other rules. Bazel and rules_go together fill the same role as the go command, so it's not necessary to use the go command in a Bazel workspace.

That said, it's usually still a good idea to follow conventions required by the go command (e.g., one package per directory, package paths match directory paths). Tools that aren't compatible with Bazel will still work, and your project can be depended on by non-Bazel projects.

Does this work with Go modules?

Yes, but not directly. Bazel ignores go.mod files, and all package dependencies must be expressed through deps attributes in targets described with go_library and other rules.

You can download a Go module at a specific version as an external repository using go_repository, a workspace rule provided by gazelle. This will also generate build files using gazelle.

You can import go_repository rules from a go.mod file using gazelle update-repos.

What's up with the go_default_library name?

This was used to keep import paths consistent in libraries that can be built with go build before the importpath attribute was available.

In order to compile and link correctly, rules_go must know the Go import path (the string by which a package can be imported) for each library. This is now set explicitly with the importpath attribute. Before that attribute existed, the import path was inferred by concatenating a string from a special go_prefix rule and the library's package and label name. For example, if go_prefix was github.com/example/project, for a library //foo/bar:bar, rules_go would infer the import path as github.com/example/project/foo/bar/bar. The stutter at the end is incompatible with go build, so if the label name was go_default_library, the import path would not include it. So for the library //foo/bar:go_default_library, the import path would be github.com/example/project/foo/bar.

Since go_prefix was removed and the importpath attribute became mandatory (see #721), the go_default_library name no longer serves any purpose. We may decide to stop using it in the future (see #265).

How do I cross-compile?

You can cross-compile by setting the --platforms flag on the command line. For example:

$ bazel build --platforms=@io_bazel_rules_go//go/toolchain:linux_amd64 //cmd

By default, cgo is disabled when cross-compiling. To cross-compile with cgo, add a _cgo suffix to the target platform. You must register a cross-compiling C/C++ toolchain with Bazel for this to work.

$ bazel build --platforms=@io_bazel_rules_go//go/toolchain:linux_amd64_cgo //cmd

Platform-specific sources with build tags or filename suffixes are filtered automatically at compile time. You can selectively include platform-specific dependencies with select expressions (Gazelle does this automatically).

go_library(
    name = "foo",
    srcs = [
        "foo_linux.go",
        "foo_windows.go",
    ],
    deps = select({
        "@io_bazel_rules_go//go/platform:linux_amd64": [
            "//bar_linux",
        ],
        "@io_bazel_rules_go//go/platform:windows_amd64": [
            "//bar_windows",
        ],
        "//conditions:default": [],
    }),
)

To build a specific go_binary or go_test target for a target platform, set the goos and goarch attributes on that rule. This is useful for producing multiple binaries for different platforms in a single build. You can equivalently depend on a go_binary or go_test rule through a Bazel configuration transition on //command_line_option:platforms (there are problems with this approach prior to rules_go 0.23.0).

How do I access testdata?

Bazel executes tests in a sandbox, which means tests don't automatically have access to files. You must include test files using the data attribute. For example, if you want to include everything in the testdata directory:

go_test(
    name = "foo_test",
    srcs = ["foo_test.go"],
    data = glob(["testdata/**"]),
    importpath = "github.com/example/project/foo",
)

By default, tests are run in the directory of the build file that defined them. Note that this follows the Go testing convention, not the Bazel convention followed by other languages, which run in the repository root. This means that you can access test files using relative paths. You can change the test directory using the rundir attribute. See go_test.

Gazelle will automatically add a data attribute like the one above if you have a testdata directory unless it contains buildable .go files or build files, in which case, testdata is treated as a normal package.

Note that on Windows, data files are not directly available to tests, since test data files rely on symbolic links, and by default, Windows doesn't let unprivileged users create symbolic links. You can use the github.com/bazelbuild/rules_go/go/tools/bazel library to access data files.

How do I access go_binary executables from go_test?

The location where go_binary writes its executable file is not stable across rules_go versions and should not be depended upon. The parent directory includes some configuration data in its name. This prevents Bazel's cache from being poisoned when the same binary is built in different configurations. The binary basename may also be platform-dependent: on Windows, we add an .exe extension.

To depend on an executable in a go_test rule, reference the executable in the data attribute (to make it visible), then expand the location in args. The real location will be passed to the test on the command line. For example:

go_binary(
    name = "cmd",
    srcs = ["cmd.go"],
)

go_test(
    name = "cmd_test",
    srcs = ["cmd_test.go"],
    args = ["$(location :cmd)"],
    data = [":cmd"],
)

See //tests/core/cross for a full example of a test that accesses a binary.

Alternatively, you can set the out attribute of go_binary to a specific filename. Note that when out is set, the binary won't be cached when changing configurations.

go_binary(
    name = "cmd",
    srcs = ["cmd.go"],
    out = "cmd",
)

go_test(
    name = "cmd_test",
    srcs = ["cmd_test.go"],
    data = [":cmd"],
)

How do I avoid conflicts with protocol buffers?

See Avoiding conflicts in the proto documentation.

Can I use a vendored gRPC with go_proto_library?

This is not supported. When using go_proto_library with the @io_bazel_rules_go//proto:go_grpc compiler, an implicit dependency is added on @org_golang_google_grpc//:go_default_library. If you link another copy of the same package from //vendor/google.golang.org/grpc:go_default_library or anywhere else, you may experience conflicts at compile or run-time.

If you're using Gazelle with proto rule generation enabled, imports of google.golang.org/grpc will be automatically resolved to @org_golang_google_grpc//:go_default_library to avoid conflicts. The vendored gRPC should be ignored in this case.

If you specifically need to use a vendored gRPC package, it's best to avoid using go_proto_library altogether. You can check in pre-generated .pb.go files and build them with go_library rules. Gazelle will generate these rules when proto rule generation is disabled (add # gazelle:proto disable_global to your root build file).

How do I use different versions of dependencies?

See Overriding dependencies for instructions on overriding repositories declared in go_rules_dependencies.

How do I run Bazel on Travis CI?

References:

In order to run Bazel tests on Travis CI, you'll need to install Bazel in the before_install script. See our configuration file linked above.

You'll want to run Bazel with a number of flags to prevent it from consuming a huge amount of memory in the test environment.

  • --host_jvm_args=-Xmx500m --host_jvm_args=-Xms500m: Set the maximum and initial JVM heap size. Keeping the same means the JVM won't spend time growing the heap. The choice of heap size is somewhat arbitrary; other configuration files recommend limits as high as 2500m. Higher values mean a faster build, but higher risk of OOM kill.
  • --bazelrc=.test-bazelrc: Use a Bazel configuration file specific to Travis CI. You can put most of the remaining options in here.
  • build --spawn_strategy=standalone --genrule_strategy=standalone: Disable sandboxing for the build. Sandboxing may fail inside of Travis's containers because the mount system call is not permitted.
  • test --test_strategy=standalone: Disable sandboxing for tests as well.
  • --local_resources=1536,1.5,0.5: Set Bazel limits on available RAM in MB, available cores for compute, and available cores for I/O. Higher values mean a faster build, but higher contention and risk of OOM kill.
  • --noshow_progress: Suppress progress messages in output for cleaner logs.
  • --verbose_failures: Get more detailed failure messages.
  • --test_output=errors: Show test stderr in the Travis log. Normally, test output is written log files which Travis does not save or report.

Downloads on Travis are relatively slow (the network is heavily contended), so you'll want to minimize the amount of network I/O in your build. Downloading Bazel and a Go SDK is a huge part of that. To avoid downloading a Go SDK, you may request a container with a preinstalled version of Go in your .travis.yml file, then call go_register_toolchains(go_version = "host") in a Travis-specific WORKSPACE file.

You may be tempted to put Bazel's cache in your Travis cache. Although this can speed up your build significantly, Travis stores its cache on Amazon, and it takes a very long time to transfer. Clean builds seem faster in practice.

How do I test a beta version of the Go SDK?

rules_go only supports official releases of the Go SDK. However, you can still test beta and RC versions by passing a version like "1.16beta1" to go_register_toolchains. See also go_download_sdk.

load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")

go_rules_dependencies()

go_register_toolchains(version = "1.17beta1")
Owner
Bazel
Bazel organization
Bazel
Comments
  • builds with cgo appear to miss .S assembly files

    builds with cgo appear to miss .S assembly files

    What version of rules_go are you using?

    0.35.0

    What version of gazelle are you using?

    0.27.0

    What version of Bazel are you using?

    Build label: 5.4.0

    Does this issue reproduce with the latest releases of all the above?

    Yes

    What operating system and processor architecture are you using?

    $ lsb_release -a
    Distributor ID: Ubuntu
    Description:    Ubuntu 22.04.1 LTS
    Release:        22.04
    Codename:       jammy
    

    Any other potentially useful information about your toolchain?

    What did you do?

    I am attempting to build Go program using the popular zstd package from DataDog This library vendors zstd, which includes accelerated operations in the .S file.

    This works well with the vanilla go toolchain, however building this via rules_go fails to pick up an .S file for amd64, causing it to fail during link time

    $ git clone https://github.com/tals/bazel-rulesgo-broken-asm-repro
    $ cd bazel-rulesgo-broken-asm-repro
    $ go run main.go
    Hello, World!
    
    $ bazel run  //:hello-go
    
    INFO: Analyzed target //:hello-go (26 packages loaded, 195 targets configured).
    INFO: Found 1 target...
    ERROR: /home/tal/.cache/bazel/_bazel_tal/d6d42962320318bd35977430f4d78b15/external/com_github_datadog_zstd/BUILD.bazel:3:11: GoCompilePkg external/com_github_datadog_zstd/zstd.a failed: (Exit 1): builder failed: error executing command bazel-out/k8-opt-exec-2B5CBBC6/bin/external/go_sdk/builder compilepkg -sdk external/go_sdk -installsuffix linux_amd64 -src external/com_github_datadog_zstd/errors.go -src ... (remaining 211 arguments skipped)
    
    Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
    /tmp/rules_go_work-585792782/cgo/github.com/DataDog/zstd/_x16.o:huf_decompress.c:function HUF_decompress4X1_usingDTable_internal_bmi2_asm: error: undefined reference to 'HUF_decompress4X1_usingDTable_internal_bmi2_asm_loop'
    /tmp/rules_go_work-585792782/cgo/github.com/DataDog/zstd/_x16.o:huf_decompress.c:function HUF_decompress4X2_usingDTable_internal_bmi2_asm: error: undefined reference to 'HUF_decompress4X2_usingDTable_internal_bmi2_asm_loop'
    collect2: error: ld returned 1 exit status
    compilepkg: error running subcommand /usr/bin/gcc: exit status 1
    Target //:hello-go failed to build
    Use --verbose_failures to see the command lines of failed build steps.
    INFO: Elapsed time: 4.087s, Critical Path: 3.93s
    INFO: 2 processes: 2 internal.
    FAILED: Build did NOT complete successfully
    FAILED: Build did NOT complete successfully
    

    The Gazelle-generated project does include the .S file, however:

    go_library(
        name = "zstd",
        srcs = [
            ...
            "huf_compress.c",
            "huf_decompress.c",
            "huf_decompress_amd64.S", # <---
    

    What did you expect to see?

    Hello, World!

    What did you see instead?

    Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
    /tmp/rules_go_work-585792782/cgo/github.com/DataDog/zstd/_x16.o:huf_decompress.c:function HUF_decompress4X1_usingDTable_internal_bmi2_asm: error: undefined reference to 'HUF_decompress4X1_usingDTable_internal_bmi2_asm_loop'
    /tmp/rules_go_work-585792782/cgo/github.com/DataDog/zstd/_x16.o:huf_decompress.c:function HUF_decompress4X2_usingDTable_internal_bmi2_asm: error: undefined reference to 'HUF_decompress4X2_usingDTable_internal_bmi2_asm_loop'
    collect2: error: ld returned 1 exit status
    compilepkg: error running subcommand /usr/bin/gcc: exit status 1
    Target //:hello-go failed to build
    Use --verbose_failures to see the command lines of failed build steps.
    INFO: Elapsed time: 4.087s, Critical Path: 3.93s
    INFO: 2 processes: 2 internal.
    FAILED: Build did NOT complete successfully
    FAILED: Build did NOT complete successfully
    
  • fix: Relative path of embedsrc

    fix: Relative path of embedsrc

    What type of PR is this? Bug fix

    What does this PR do? Why is it needed?

    The new relativize introduced by https://github.com/bazelbuild/rules_go/pull/3285 fails if also includes generated code because the library_to_source appends the src with the generated_srcs, so instead of using the last src_dir, it uses the first

    Which issues(s) does this PR fix?

    Fixes # 3405

    Other notes for review

  • support go:embed of generated files failing

    support go:embed of generated files failing

    What version of rules_go are you using?

    0.37.0

    What version of gazelle are you using?

    0.28.0

    What version of Bazel are you using?

    5.4.0

    Does this issue reproduce with the latest releases of all the above?

    Yes

    What operating system and processor architecture are you using?

    OSX x64

    Any other potentially useful information about your toolchain?

    What did you do?

    When I tried to run the compilation process with the latest release, the embedsrc was failing when using go_path, due a relativize issue

    What did you expect to see?

    Compiling correctly

    What did you see instead?

     File "/external/io_bazel_rules_go/go/private/tools/path.bzl", line 89, column 51, in _go_path_impl
                    dst = pkg.dir + "/" + paths.relativize(embedpath, src_dir)
            File "external/bazel_skylib/lib/paths.bzl", line 182, column 13, in _relativize
                    fail("Path '%s' is not beneath '%s'" % (path, start))
    Error in fail: Path 'services/test/graphql/schema.graphql' is not beneath 'bazel-out/darwin-fastbuild/bin/services/test/graphql'
    
  • Flag --incompatible_disable_starlark_host_transitions will break rules_go in Bazel 7.0

    Flag --incompatible_disable_starlark_host_transitions will break rules_go in Bazel 7.0

    Incompatible flag --incompatible_disable_starlark_host_transitions will be enabled by default in the next major release (Bazel 7.0), thus breaking rules_go. Please migrate to fix this and unblock the flip of this flag.

    The flag is documented here: bazelbuild/bazel#17032.

    Please check the following CI builds for build and test results:

    Never heard of incompatible flags before? We have documentation that explains everything. If you have any questions, please file an issue in https://github.com/bazelbuild/continuous-integration.

  • `go_download_sdk` should use the exec OS and arch instead of the host

    `go_download_sdk` should use the exec OS and arch instead of the host

    My goal is to compile something using rules_go on a macOS arm64 host, using a macOS amd64 remote executor.

    From my understanding of reading the bazel docs on platforms, it seems like instead of downloading the toolchain for the host platform, it should download it for the exec platform.

    https://github.com/bazelbuild/rules_go/blob/1a8fe64877c6e71dbbf51cdc8ceb2eb10c13e521/go/private/sdk.bzl#L359-L372

    What version of rules_go are you using?

    https://github.com/bazelbuild/rules_go/releases/tag/v0.36.0

    What version of gazelle are you using?

    https://github.com/bazelbuild/bazel-gazelle/releases/tag/v0.26.0

    What version of Bazel are you using?

    6.0.0rc4

    Does this issue reproduce with the latest releases of all the above?

    Yes.

    What operating system and processor architecture are you using?

    Host: macOS 13 (arm64) Exec: macOS 13 (amd64)

    Any other potentially useful information about your toolchain?

    Using remote execution.

    What did you do?

    $ git clone https://github.com/envoyproxy/envoy.git
    $ cd envoy/mobile
    # ./bazelw build \
      --tls_client_certificate=<redacted> \
      --tls_client_key=<redacted> \
      --config remote-ci-macos \
      //library/common:envoy_main_interface_lib
    

    What did you expect to see?

    I expected go_download_sdk to download the darwin/arm64 version of the SDK.

    What did you see instead?

    I see a toolchain resolution error:

    ERROR: /private/var/tmp/_bazel_jsimard/e99b8d924fe95f277e909ecdb8681535/external/com_envoyproxy_protoc_gen_validate/BUILD:11:10: While resolving toolchains for target @com_envoyproxy_protoc_gen_validate//:protoc-gen-validate: No matching toolchains found for types @io_bazel_rules_go//go:toolchain.

    Here's a link to the invocation on EngFlow: https://envoy.cluster.engflow.com/invocation/7c14f5f1-1765-4589-8562-b1c5fc86318a#console


    With https://github.com/envoyproxy/envoy/pull/24501 I can get past the toolchain resolution error when using remote exec on a macOS amd64 host and a macOS arm64 remote executor, but then the toolchain resolution fails on Linux (CI logs).

  • Support coverageredesign (Go 1.20+)

    Support coverageredesign (Go 1.20+)

    @fmeum

    Go 1.20 changes the way coverage is done by default (see https://tip.golang.org/doc/go1.20#cover). This is controlled by the coverageredesign GOEXPERIMENT.

    We can work around this by setting GOEXPERIMENT=nocoverageresign, but should update the way coverage is done so that's not necessary.

Generate types and service clients from protobuf definitions annotated with http rules.

protoc-gen-typescript-http Generates Typescript types and service clients from protobuf definitions annotated with http rules. The generated types fol

Nov 22, 2022
The rest api that can manage the iptables rules of the remote host

fiewall-api firewall api是基于firewalld来远程管理iptables规则的rest-api,无需部署agent Features 指定一个主机ip,让这个主机上的iptables增加一个规则 处理单个IP或CIDR范围(xx.xx.xx.xx/mask,mac,inte

Mar 24, 2022
Read k8S-source-code notes, help quickly understand the K8S-code organization rules
Read k8S-source-code notes, help quickly understand the K8S-code organization rules

K8S源码阅读笔记 以下笔记针对 kubernetes V1.23.1(截至2022年01月01日最新版本),并不保证对其它版本的有效性 一、架构图 二、阅读前准备 由于kubernetes项目巧妙的设计和代码高度的封装性,建议在阅读代码前,尽可能的进行以下内容的准备: 1. 编程知识配备 编程语准

Feb 16, 2022
KeeneticRouteToVpn is simple app updating Keenetic Router rules for some hosts to go through VPN interface.

KeeneticRouteToVpn KeeneticRouteToVpn is simple app updating Keenetic Router rules for some hosts to go through VPN interface. It has defaults values

Oct 8, 2022
Squzy - is a high-performance open-source monitoring, incident and alert system written in Golang with Bazel and love.

Squzy - opensource monitoring, incident and alerting system About Squzy - is a high-performance open-source monitoring and alerting system written in

Dec 12, 2022
Baize - A minimum implement of bazel remote execution
Baize - A minimum implement of bazel remote execution

BAIZE Baize, mythical creatures in ancient Chinese mythology, who can speak with

Jul 24, 2022
A Golang library to manipulate strings according to the word parsing rules of the UNIX Bourne shell.

shellwords A Golang library to manipulate strings according to the word parsing rules of the UNIX Bourne shell. Installation go get github.com/Wing924

Sep 27, 2022
A natural language date/time parser with pluggable rules

when when is a natural language date/time parser with pluggable rules and merge strategies Examples tonight at 11:10 pm at Friday afternoon the deadli

Dec 26, 2022
A rest application to update firewalld rules on a linux server

Firewalld-rest A REST application to dynamically update firewalld rules on a linux server. Firewalld is a firewall management tool for Linux operating

Jan 2, 2023
⚙️ Convert HTML to Markdown. Even works with entire websites and can be extended through rules.
⚙️ Convert HTML to Markdown. Even works with entire websites and can be extended through rules.

html-to-markdown Convert HTML into Markdown with Go. It is using an HTML Parser to avoid the use of regexp as much as possible. That should prevent so

Jan 6, 2023
Validate Golang request data with simple rules. Highly inspired by Laravel's request validation.
Validate Golang request data with simple rules. Highly inspired by Laravel's request validation.

Validate golang request data with simple rules. Highly inspired by Laravel's request validation. Installation Install the package using $ go get githu

Dec 29, 2022
An idiomatic Go (golang) validation package. Supports configurable and extensible validation rules (validators) using normal language constructs instead of error-prone struct tags.

ozzo-validation Description ozzo-validation is a Go package that provides configurable and extensible data validation capabilities. It has the followi

Jan 7, 2023
Application for HTTP benchmarking via different rules and configs
Application for HTTP benchmarking via different rules and configs

Go Benchmark App The efficiency and speed of application - our goal and the basic idea. Application for HTTP-benchmarking via different rules and conf

Dec 24, 2022
Generate types and service clients from protobuf definitions annotated with http rules.

protoc-gen-typescript-http Generates Typescript types and service clients from protobuf definitions annotated with http rules. The generated types fol

Nov 22, 2022
A natural language date/time parser with pluggable rules

when when is a natural language date/time parser with pluggable rules and merge strategies Examples tonight at 11:10 pm at Friday afternoon the deadli

Dec 26, 2022
Generate Prometheus rules for your SLOs

prometheus-slo Generates Prometheus rules for alerting on SLOs. Based on https://developers.soundcloud.com/blog/alerting-on-slos. Usage Build and Run

Nov 27, 2022
A parser generator where rules defined as go structs and code generation is optional

A parser generator where rules defined as go structs and code generation is optional. The concepts are introduced in the simple example below.

Jul 1, 2022
go-linters How to grow Go code as a bonsai: the style, the rules, the linters

How to grow Go code as a bonsai: the style, the rules, the linters (Definition 2021 Hackaton) Build go build -buildmode=plugin plugin/plugin.go Run go

Nov 9, 2022
An easy to use relay for cftools webhook events piped to Discord when filter rules match.

CFTools Relay CFTools Relay is an easy-to-use, still in development, tool that allows you to subscribe to CFTools Cloud Webhook events and forward the

Nov 22, 2022