Make the rules easily reusable in workflows.

[hsyed]

We should be able to reuse the docker rules logic in other rules. Unless I am missing something we can't bazel run from within a bazel run. A lot of this work will be done for rules_k8s it would be great if the problem is addressed in a general way.

Use cases:

• Minikube environment variables injection pre incremental loading Add support for minikube rules_k8s#9.
• Authentication pre (and post) hook for pull and push rules (authentication). #147 (although this should probably have support in the rules).
• Building CI systems.

What I tried:

Tried to prototype a higher level rule that would get a "handle" to a docker_build runnable and then do something before or after incrementally loading the image.

ci_environment = rule(
  attrs = {
    "platform": attr.label(single_file = True ,executable=True, cfg = "host"),  # <-- docker_build target
  },
  executable=True,
  implementation = _impl
)

Somewhere in the rule

ctx.file_action(
  output=ctx.outputs.executable,
  content="./%s" % ctx.executable.platform.short_path,
  executable=True
)

Problems

It's not straight forward to setup the runtime context of the target rules. I tried to repurpose the logic by studying the internals and this but even if I had managed to get it to work it would not be the way forward as it depends on the internals.

What I hope for

A simple way to reuse the logic in the rules defined here. What would be nicest is a simple handle to the target that I can execute at some arbitrary point in a rule / genrule. If this is not possible some utility functions with examples would be usefull. --e.g.,

def _my_rule_impl(ctx):
  info = DefaultInfo()
  run_docker_build(ctx, ctx.attr.my_image, info)
  // my actions
  return info

[mattmoor]

@hsyed There is clearly a bug today where:

  # Works
  bazel run path/to:docker_build
  # Does not work
  bazel build path/to:docker_build
  bazel-bin/path/to/docker_build     <-- This is essentially what you want to include into other rules.

I bet fixing this would unblock you (if you "hold it" right, which is often harder than it looks with Bazel/Skylark), so I will poke at this a little to see if I can figure out how I'm "holding it wrong". :)

For your first two scenarios, I think we have a tentative plan or a solution (I've updated the linked issues).

The CI system bit is a little vague, but I'm happy to discuss (and/or pull folks in to help).

FWIW, part of the reason we do the docker load during run today is that it isn't hermetic due to the daemon dependency, so your sketch of a rule implementation probably violates that.

[mattmoor]

@hsyed Can you try some of your logic that wraps the rules with the linked PR? If you are still having issues, I'd be happy to TAL if you send me a pointer to some WIP rules?

[hsyed]

@mattmoor docker_build() targets now seems to work with the change you pushed:

def _setup_deploy_rule(kwargs):
  native.genrule(
      name = "local",
      tools = ["//:platform.image"],
      outs = ["local_deploy.sh"],
      cmd = """
# I was trying to do a $$(minikube docker-env) here but no joy -- i'll await the work from rules_k8s.
echo "$(location //:platform.image)" >$@
""",
      local = 1,
      executable = True,
  )

docker_push rules do however do not work:

def _setup_deploy_rule(kwargs):
  native.genrule(
      name = "local",
      tools = ["//ci:ax-dev-staging"], # also tried relative target path --i.e., :ax-dev-staging
      outs = ["local_deploy.sh"],
      cmd = """
echo "$(location //ci:ax-dev-staging)" >$@
""",
      local = 1,
      executable = True,
  )

It reports this, I get the same when trying to run it via bazel-bin/ci/ax-dev-staging:

./pusher/file/pusher.par: No such file or directory

[mattmoor]

I will take a look, it should be pretty easy to reproduce. Sorry for the trouble.

[mattmoor]

I pushed #153 which should make build/run separable for push as well.

[mattmoor]

Ok, #153 is in, so let me know if you are unblocked (or if I should keep whacking moles).

[mattmoor]

@hsyed I just want to follow up to see if I can close this now? Are there any remaining issues for you?

[hsyed]

I'd Want to do some more work on what I had in mind, But I'm blocked on the incremental load into minikube front. I wanted to write a deploy step that could switch between loading into minikube vs a docker push depending on the "environment" being pushed to.

One thing that occurs to me is that the pusher script will be primed to push to a specific registry:tag, I wonder if it's possible to get a pusher that takes this as an argument.

Have you made any more progress on the minikube front ? I still have to set the docker machine env before calling into bazel.

[mattmoor]

You can pass --name to the pusher script to override where it pushes.

@dlorenc for the minikube stuff.

[mattmoor]

@r2d4 may know too