This script needs/uses a custom `BASHBREW_LIBRARY` directory, but it stores that value in the exported environment slightly too soon such that `generate-stackbrew-library.sh` picks it up (and shouldn't be).
We often use "`BASHBREW_LIBRARY` is unset (or empty)" as a conditional for whether to fall back to using "https://github.com/docker-library/official-images/raw/HEAD/library/" as an explicit prefix for querying "source of truth" values for things like supported parent architectures.
These two things collided in cc2dc88e04 (and similar commits) because the script saw `BASHBREW_LIBRARY` set, trusted it, but then fails to find the parent image.
This is the cleanest place to fix this such that `generate-stackbrew-library.sh` can take `BASHBREW_LIBRARY` from the provided environment instead of using our generated value.
This should be more reliable/correct than `uname -m` (because we're almost always looking for the *userspace* architecture, not the kernel architecture).
- "workflow_dispatch" so we can trigger manually
- "concurrency" so we avoid over-triggering when updating PRs/branches
- multi-line string in GITHUB_OUTPUT for better output and less flakiness
This *should* be generally safe since we got most/all downstream consumers to pin to a release (or they're building bashbrew from the same commit they're getting the script from).
In the case of base images (`debian`, `alpine`, `ubuntu`, etc), using a `Dockerfile` as our method of ingestion doesn't really buy us very much. It made sense at the time it was implemented ("all `Dockerfile`, all the time"), but at this point they're all some variation on `FROM scratch \n ADD foo.tar.xz / \n CMD ["/bin/some-shell"]`, and cannot reasonably be "rebuilt" when their base image changes (which is one of the key functions of the official images) since they _are_ the base images in question.
Functionally, consuming a tarball in this way isn't _that_ much different from consuming a raw tarball that's part of, say, an OCI image layout (https://github.com/opencontainers/image-spec/blob/v1.0.2/image-layout.md) -- it's some tarball plus some metadata about what to do with it.
For less trivial images, there's a significant difference (and I'm not proposing to use this for anything beyond simple one-layer base images), but for a single layer this would be basically identical.
As a more specific use case, the Debian `rootfs.tar.xz` files are currently [100% reproducible](https://github.com/debuerreotype/debuerreotype). Unfortunately, some of that gets lost when it gets imported into Docker, and thus it takes some additional effort to get from the Docker-generated rootfs back to the original debuerreotype-generated file.
This adds the ability to consume an OCI image directly, to go even further and have a 100% fully reproducible image digest as well, which makes it easier to trace a given published image back to the reproducible source generated by the upstream tooling (especially if a given image is also pushed by the maintainer elsewhere).
Here's an example `oci-debian` file I was using for testing this:
Maintainers: Foo (@bar)
GitRepo: https://github.com/tianon/docker-debian-artifacts.git
GitFetch: refs/heads/oci-arm32v5
Architectures: arm32v5
GitCommit: d6ac440e7760b6b16e3d3da6f2b56736b9c10065
Builder: oci-import
File: index.json
Tags: bullseye, bullseye-20221114, 11.5, 11, latest
Directory: bullseye/oci
Tags: bullseye-slim, bullseye-20221114-slim, 11.5-slim, 11-slim
Directory: bullseye/slim/oci
I've got a very pathological branch of a certain repository where this makes a parallelized (four concurrent invocations) generation change from ~3 _minutes_ down to ~13 _seconds_.
Tianon Gravi