When are bottles built during the release process for a new version of a homebrew-core formula?

[rgoldberg]

Output of brew config

n/a

Output of brew doctor

n/a

Description of issue

When are bottles built during the release process for a new version of a homebrew-core formula?

e.g., this autogenerated comment on a PR links to a workflow run which includes this job whose Pull PR bottles step obtains bottles from the artifacts of the PR.

I couldn't, however, discern where in prior workflows or in that workflow the bottles were actually built.

Any help would be appreciated.

Thanks.

[SMillerDev]

They are the build that happens before. Those bottles are then used to run tests on for CI

[rgoldberg]

@SMillerDev Can you let me know the GitHub workflow, job, and step that actually builds the bottles?

I couldn’t find what workflow builds them.

Maybe I completely missed it or maybe that workflow is visible only to Homebrew team members…

I’m trying to understand what options I can use to affect how the bottles are built, so seeing the code that builds them would be helpful.

Thanks again.

[SMillerDev]

You can not affect in any way outside of the Formula methods how bottles are built. Doing so would be a severe security issue in the homebrew project.

[alebcay]

For transparency - the relevant GitHub Actions step is here.

The code for the brew test-bot command is at https://github.com/Homebrew/homebrew-test-bot. It acts as a harness around various brew commands to test and build the entire lifecycle of a formula. Depending on what you're trying to accomplish, you could consider forking it if you want to build formulae for a custom tap with a modified process.

Within homebrew-core, the aspects of the build process which are intended to be configurable for individual formulae are exposed via the DSL (in formula code).

[rgoldberg]

@alebcay Thanks for the links.

For the merged PRs that I’ve looked through, the logs for the CI workflow do not include any jobs named tests. I see many other jobs from that workflow. It’s possible that tests was somehow renamed as ${{ matrix.name }} in the job list, and not run. (if that was the case, however, how did the later workflow get the bottles from the PR’a artifacts, and how would the checksum for the bottles have changed from their values in the previous version of the formula?)

Can you see a tests job in the CI workflow here? If so, I guess I don’t have the requisite permissions to see it.

Thanks for the help.

[alebcay]

The tests job runs as a matrix - you can see this on the flow diagram in the summary view here, for instance.

The names of the individual jobs in the matrix are the platform it runs on, e.g. "macOS 15-arm64". Note that this matrix job may not always be run (previous steps may cause the tests job to be skipped).

The tests job runs as part of the pre-merge workflow. If you're looking at the last workflow for a PR which has already been merged, you probably won't see it there, since it is a different workflow that runs upon merge/acceptance.

[rgoldberg]

@alebcay Thangs again for the info.

I found the logs for the workflow, job, and step that built the bottles in which I am interested.

Earlier, I was using the GitHub iPhone app, which only seemed to let me see the workflows for the most recent commit of in the PR, which was for updating the bottle checksums, not for the submitted PR changes.

On the desktop GitHub site, I can switch commits with a dropdown on the left. I didn't see an equivalent dropdown on the iPhone.

That's what prevented me from finding the logs.