Consider Bazel integration

[hausdorff]

[anguslees]

I'm happy to switch to bazel - what I don't want to do is to maintain two build systems in parallel (like k8s). And of course the downside of switching to any "non-standard" build system is the additional hurdle for casual contributors.

.. So I think we'd have to become complex enough that the regular "go get ..." machinery no longer worked before considering something more flexible. Are we at that point? What's the motivation for considering something other than the status-quo?

[hausdorff]

Ah, sorry, I wrote this in a rush. This was less a "let's build with Bazel" and more "let's see if we can make it really convenient for people to use Bazel to as their CI/CD."

[anguslees]

You mean https://github.com/mmikulicic/rules_ksonnet ? ;)

[hsyed]

I quickly ported project to Bazel last night(#133) as I wanted to try out kubecfg on our CI servers.

[hsyed]

@hausdorff i've just synced the branch and updated the build, any chance the pr could get merged in ? we are using kubecfg in bazel and it would be great to be able to refer to this repo directly.

[peternavr]

Any updates?

[anguslees]

Any updates?

I remain extremely reluctant to maintain more than one build system without a strong reason. I appreciate that bazel BUILD files can be autogenerated quite effectively using gazelle, etc - but as far as I can see that just means there's even less value in maintaining a copy of those generated files centrally.

Now, if there's some change that will make it easier to integrate with 3rd-party build tools (bazel, make, cmake, scons, bitbake, etc, etc) then I'm super happy to discuss that. The move from cgo to pure go, for example, was all about making builds easier.

I guess I'm saying: help me understand why this is important enough to bazel consumers to be worth putting additional work on all kubecfg contributors. What's the bazel workflow like? If you have to manually git clone anyway, perhaps we can add the BUILD files lazily and just say "you have to git clone .. and also run this gen-bazel.sh script"?

[mkmik]

@hsyed I'm able to reference kubecfg from a bazel project with:

go_repository(
    name = "kubecfg",
    build_file_generation = "on",
    build_file_name = "BUILD.bazel",
    importpath = "github.com/ksonnet/kubecfg",
    strip_prefix = "kubecfg-0.9.0",
    type = "zip",
    urls = ["https://codeload.github.com/ksonnet/kubecfg/zip/v0.9.0"],
)

then I just call the binary in a genrule. I was too lazy to download the binary, and it's not a big deal because of caching.

I agree with @anguslees that there doesn't seem to be any point to maintain both Go tool + bazel build systems and bazel alone would needlessly steepen the barrier to entry for new contributors.

That said, if anything in the kubecfg repository is getting in the way (as when we had some vendored BUILD and BUILD.bazel files, which were addressed by updating to a newer k8s client) we should fix it. For now, I don't see the reason to explicitly add bazel support inside the kubecfg repo itself. Am I missing something?

On the other hand: it would be nice if we could use kubecfg from a bazel CI/CD workflow. As @anguslees mentioned, I played a bit with it in https://github.com/mmikulicic/rules_ksonnet but that repo is rotten, I'll take a stab at resurrecting it.

In the meantime I'm getting some value from a simple rule like this:

def kubecfg_to_yaml(name, src, deps=[], vars={}, visibility=None):
  """
  Compile a jsonnet input into a static yaml file using kubecfg show.
  """
  vs = ",".join(["%s=%s" % (k, v) for k, v in vars.items()])

  native.genrule(
    name = name,
    srcs = [src] + deps,
    outs = ["%s.yaml" % (name,)],
    cmd = "$(location @kubecfg//:kubecfg) show $(location %s) >$(@) -V %s" % (src, vs),
    tools = ["@kubecfg//:kubecfg"],
    visibility = visibility,
  )

def kubecfg_test(name, src, deps=[]):
  native.sh_test(
    name = name,
    data = [src, "@kubecfg//:kubecfg"] + deps,
    srcs = ["kubecfg_validate.sh"],
    args = ["--kubecfg", "$(location @kubecfg//:kubecfg)", "$(location %s)" % (src,)],
  )

used as:

kubecfg_to_yaml(
    name = "dev",
    src = "dev/frobnicator.jsonnet",
    vars = vars,
    visibility = ["//visibility:public"],
    deps = glob([
        "dev/conf/*.json",
        "dev/conf/*.jsonnet",
    ]) + [
        ":common",
    ],
)

kubecfg_test(
    name = "dev_test",
    src = ":dev",
)

....

I'd love to figure out how to do more than just validation, but I think the home for that work would be in a rules_kubecg repo rather than in here. WDYT?