Mark the `apko` module extension as reproducible to reduce bzlmod lockfile size and churn

[Silic0nS0ldier]

The apko module extension translates apko.lock.json into repositories (much like rules_js does with pnpm-lock.yaml) which is a reproducible operation. The MODULE.bazel.lock lockfile can be trimmed by returning module_ctx.extension_metadata(...) with reproducible = True.

At time of writing, this would drop an internal lockfile from 11.4k down to 6.7k (4.7k reduction).

Prior art: aspect-build/rules_js#1541

[joseflores314]

Did the discussion for this issue continue?

[Silic0nS0ldier]

No discussion ever took place (till now I guess).

Still keen for this.

[xnox]

Different versions of rules_apko, can have different versions of apko.

Different versions of apko, can sometimes produce different results of tarballs.

For example, ordering of metadata; some OCI metadata fields changes/improvements; bug fixes in generated apk metadata; how gzip compressed stream is produced; different cache usage = things that can lead to different outputs digest. Note these are rare but do happen multiple times a year.

If rules_apko is marked with the proposed key, is it expected that all outputs retain the same output digests upon rules_apko upgrades?

One should rebuild artifacts upon rules_apko upgrades.

[xnox]

Pointers to documentation as to what this key does, and what the requirements to set it are, would be very helpful.

So far I cannot find any extensive docs about it. Apart from a single sentence saying effectively "reproducible is reproducible".

[Silic0nS0ldier]

Attribute documented at https://bazel.build/rules/lib/builtins/module_ctx#extension_metadata:~:text=reproducible,-bool

It is more extensively documented at https://bazel.build/external/extension#specify_reproducibility_and_use_facts

[Silic0nS0ldier]

The main takeaway is that returning ctx.extension_metadata(reproducible = True) tells Bazel that the attributes for generated repositories are entirely derived from module extension inputs and any that aren't (e.g. metadata from downloads) are persisted using the new facts API (facts are persisted in the lockfile) to achieve reproducibility.

[joseflores314]

@xnox As part of this I don't think the output digests need to be preserved with different versions of apko or different versions of rules_apko as long as they are deterministic for the same version. The apko version is pinned as part of rules_apko so an upgrade of rules_apko should still create a reproducible build from the given versions.