"Fossies" - the Fresh Open Source Software Archive

Member "kubernetes-1.17.12/build/visible_to/README.md" (16 Sep 2020, 4816 Bytes) of package /linux/misc/kubernetes-1.17.12.tar.gz:

As a special service "Fossies" has tried to format the requested source page into HTML format (assuming markdown format). Alternatively you can here view or download the uninterpreted source code file. A member file download can also be achieved by clicking within a package contents listing on the according byte size field.

Package Groups Used in Kubernetes Visibility Rules


BUILD rules define dependencies, answering the question: on what packages does foo depend?

The BUILD file in this package allows one to define allowed reverse dependencies, answering the question: given a package foo, what other specific packages are allowed to depend on it?

This is done via visibility rules.

Visibility rules discourage unintended, spurious dependencies that blur code boundaries, slow CICD queues and generally inhibit progress.


Why define all package groups meant for visibility here (in one file)?

The alternative is to use special package literals directly in visibility rules, e.g.

  visibility = [

The difference in style is similar to the difference between using a named static constant like MAX_NODES rather than a literal like 12. Names are preferable to literals for intent documentation, search, changing one place rather than n, associating usage in distant code blocks, etc.

Rule Examples

Nobody outside this package can depend on me.

visibility = ["//visibility:private"],

Since this is the default, there's no reason to use this rule except as a means to override, for some specific target, some broader, whole-package visibility rule.

Anyone can depend on me (eschew this).

visibility = ["//visibility:public"],

Only some servers can depend on me.

Appropriate for, say, backend storage utilities.

visibility = ["//visible_to:server_foo","//visible_to:server_bar"].

Both some client and some server can see me.

Appropriate for shared API definition files and generated code:

visibility = ["//visible_to:client_foo,//visible_to:server_foo"],

Handy commands

Quickly check for visibility violations

bazel build --check_visibility --nobuild \
    //cmd/... //pkg/... //plugin/... \
    //third_party/... //test/... //vendor/k8s.io/...

Who depends on target q?

To create a seed set for a visibility group, one can ask what packages currently depend on (must currently be able to see) a given Go library target? It's a time consuming query.

bazel query "rdeps(...,${q})" | \
    grep go_default_library | \
    sed 's/\(.*\):go_default_library/ "\1",/'

What targets below p are visible to anyone?

A means to look for things one missed when locking down p.

bazel query "visible(...,${p}/...)"

What packages below p may target q depend on without violating visibility rules?

A means to pinpoint unexpected visibility.

bazel query "visible(${q},${p}/...)" | more

What packages does target q need?

bazel query "buildfiles(deps($q))" | \
    grep -v @bazel_tools | \
    grep -v @io_bazel_rules | \
    grep -v @io_k8s_repo_infra | \
    grep -v @local_config | \
    grep -v @local_jdk | \
    grep -v //visible_to: | \
    sed 's/:BUILD//' | \
    sort | uniq > ~/KUBECTL_BUILD.txt

or try

bazel query --nohost_deps --noimplicit_deps \
    "kind('source file', deps($q))" | wc -

How does kubectl depend on pkg/util/parsers?

bazel query "somepath(cmd/kubectl:kubectl, pkg/util/parsers:go_default_library)"