Please add context action for creating archives (tar, zip, maybe jar?)

Creating archives is a common task of Skylark rules, but today it’s difficult to do correctly. Bazel itself packages a pkg_tar rule that (1) depends on Python and (2) generates non-deterministic output (https://github.com/bazelbuild/bazel/issues/1844). This has downstream effects on every rule built on pkg_tar (see pkg_deb bug https://github.com/bazelbuild/bazel/issues/3723), and complicates life for rule authors (see timestamp hoop-jumping in rules_docker).

Bazel already depends on Apache Commons Compress, which supports creating various types of archive. It should be straightforward to wrap their tar/zip logic with a repository action. Also useful is .ar for pkg_deb, and .xz because the XZ utilities are not installed by default on Mac OS.

Example of use:

def _some_rule(ctx):
  entry_a = ctx.actions.declare_archive_entry(
    input = ctx.file.some_file,
  )
  entry_b = ctx.actions.declare_archive_entry(
    input = ctx.file.some_other_file,
  )
  archive = ctx.actions.declare_file("big_blob_of_bytes.tar.gz")
  ctx.actions.write_archive(
    output = archive,
    inputs = [entry_a, entry_b],
  )

The declare_archive_entry method would have optional parameters to override the path, permissions, metadata, and so on.

[aiuto]

I don’t know if having a built-in action is going to win. If we have remote execution, the action is running on the remote machine, so we would have to provide a binary portable to the execution environment. The blaze binary is not running there.

What I do support is adding a set of rules to rules_pkg that make defining complex package structures easier. At the bottom they can call tar or zip or a python equivalent for now. Over time we can replace these with faster (and more portable) compression tools. For reference, to any ex-Googlers, what I would like to do is export the pkgfilegroup() rule, but with a cleaned up design.

[jmillikin]

Since Bazel’s built-in rules for C++/Java/etc are being moved out to their own rule sets, I agree that building this functionality as a Starlark rule instead of ctx.actions makes sense.

I’ll close this since https://github.com/bazelbuild/bazel/issues/8857 covers it.