ci: add tarball release workflow triggered by BREW_VERSION changes

[dylanmtaylor]

Add a workflow that builds homebrew tarballs and publishes them as GitHub releases for x86_64 and aarch64. Triggered when BREW_VERSION changes (e.g. via renovate) or manually via workflow_dispatch.

Releases are tagged with the brew version from BREW_VERSION so downstream consumers like projectbluefin/dakota can track them with renovate.

Context: the tarball generation was removed from ublue-os/packages in ublue-os/packages#1182, leaving downstream consumers with a frozen March 10 tarball. This restores release publishing in this repo where the container build already happens.

[castrojo]

Can we have it monitor the brew github repo so we can run it on demand when brew updates instead of daily?

[dylanmtaylor]

Can we have it monitor the brew github repo so we can run it on demand when brew updates instead of daily?

Updated to run on new brew version instead of daily

[Copilot]

Pull request overview

Adds a GitHub Actions workflow to build the Homebrew tarball from the existing Containerfile, then publish architecture-specific tarballs plus SHA256 checksums to a GitHub Release.

Changes:

• Build container images on amd64 and arm64 runners and extract homebrew.tar.zst into per-arch artifacts.
• Aggregate artifacts, generate SHA256SUMS, and publish them as a GitHub Release tagged by BREW_VERSION.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dylanmtaylor]

@renner0e updated with new action versions

[renner0e]

this doesn't seem to work as is
https://github.com/renner0e/brew/actions/runs/24103626385/job/70321171440

Also I feel like this should be integrated in the other workflow so things can be shared and don't have to be reinvented here.

[dylanmtaylor]

Fixed the build failure -- the scratch image has no entrypoint so podman create fails. Updated to target the builder stage instead. Tested successfully on my fork: https://github.com/dylanmtaylor/brew/actions/runs/24104048140

On integrating with the existing workflow -- happy to do that if you'd prefer. The existing build.yml pushes a container image to GHCR, so we could add a job there that extracts the tarball and publishes a release after the manifest step. Want me to rework it that way?

I think this was intentionally disabled though, as brew used to have releases in the past via the packages repo.

[ledif]

The tarball produced by this workflow is already present in the OCI image that the current workflow publishes to ghcr.io/ublue-os/brew, so we would be duplicating these bits potentially unnecessarily.

Is it possible to make a change on the Dakota side: update elements/bluefin/brew-tarball.bst to extract the tarball from ghcr.io/ublue-os/brew directly using oras, pinned by OCI digest for reproducibility? I don't know enough about Buildstream to know if that's feasible or not. If it's not possible to use oras, then I am fine with approving this if it helps move Dakota along, even if we end up duplicating a few things.

[renner0e]

https://github.com/zirconium-dev/zirconium-hawaii/blob/9c90ab3aea32c4156cced847ff9a9df1a0b29544/elements/cli/brew.bst#L5

This is what is being done in zirconium

[ledif]

https://github.com/zirconium-dev/zirconium-hawaii/blob/9c90ab3aea32c4156cced847ff9a9df1a0b29544/elements/cli/brew.bst#L5

This is what is being done in zirconium

Looking at elements/cli/brew-tarball.bst, they seem to suffer from the same problem as Dakota: they are stuck with the last published brew tarball from March because we killed that workflow.

[dylanmtaylor]

The tarball produced by this workflow is already present in the OCI image that the current workflow publishes to ghcr.io/ublue-os/brew, so we would be duplicating these bits potentially unnecessarily.

Is it possible to make a change on the Dakota side: update elements/bluefin/brew-tarball.bst to extract the tarball from ghcr.io/ublue-os/brew directly using oras, pinned by OCI digest for reproducibility? I don't know enough about Buildstream to know if that's feasible or not. If it's not possible to use oras, then I am fine with approving this if it helps move Dakota along, even if we end up duplicating a few things.

I'm not sure we can easily pull files out of the image via BuildStream like that. It might be possible, I'm just not sure how to do it. From my perspective, producing the bits twice probably isn't a big deal, as it should build very quickly and the artifact size is small.

[dylanmtaylor]

https://github.com/zirconium-dev/zirconium-hawaii/blob/9c90ab3aea32c4156cced847ff9a9df1a0b29544/elements/cli/brew.bst#L5
This is what is being done in zirconium

Looking at elements/cli/brew-tarball.bst, they seem to suffer from the same problem as Dakota: they are stuck with the last published brew tarball from March because we killed that workflow.

Yeah, I'm not sure if there's an easy fix. If someone can suggest something better, I'm happy to close this PR in favor of that one. I know my solution isn't perfect here.