workflows: add per-formula command-not-found DB entry update

[ooye-sanket]

Implements the approach discussed in Homebrew/brew#20752.

Replaces the daily batch brew which-update job with a lightweight per-formula workflow that triggers on each push to main that touches a formula file.

For each changed formula it:

1. Reads sh.brew.path_exec_files from the bottle manifest
2. Pulls executables.txt via oras
3. Updates only that formula's single line or removes it if the formula is disabled, deprecated, or deleted
4. Pushes the updated file back via oras

Key design decisions:

• cancel-in-progress: false so rapid merges queue rather than clobber each other (per Rylan12's spec in Remove brew which-update brew#20752)
• Uses github.sha^..github.sha diff-tree range to correctly handle merge commits
• No-ops if the formula's entry is already up to date

Partial implementation of Homebrew/brew#20752 brew which-update removal in homebrew/brew is a separate follow-up.

@MikeMcQuaid can you please review it!!

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

• AI was used to generate or assist with generating this PR. Please specify below how you used AI to help you, and what steps you have taken to manually verify the changes.

---

[MikeMcQuaid]

Great work so far @ooye-sanket!

[ooye-sanket]

Thanks for the review @MikeMcQuaid! I've addressed all the feedback:

• Moved all the shell logic into a new brew which-entry command in
  homebrew/brew: Add which entry command brew#21790
• Replaced custom git diff-tree logic with brew test-bot --only-formulae-detect
• Simplified all if: conditions to single lines
• Removed run: | where possible
• Fixed zizmor template injection by moving ${{ }} expressions to env: vars
• Added missing newline at end of file

[MikeMcQuaid]

Looks better! Let's get Homebrew/brew#21790 merged first.

[ooye-sanket]

@MikeMcQuaid Added the has-changes boolean step as suggested — all 5 repeated if: conditions now reference steps.has-changes.outputs.result == 'true'. All CI checks are passing. Ready for re-review!

[MikeMcQuaid]

Thanks @ooye-sanket, let's try this out!

[MikeMcQuaid]

Actually holding merge until https://github.com/Homebrew/brew/pull/21790/changes is in!

[Rylan12]

This seems good as a first pass to me, and I think we can merge this.

I wonder if a different approach could be even better:

Instead of having this run as its own job, what if we tack this on to the publish-commit-bottles.yml job. That job already runs pr-pull to download the bottles, so I wonder if we could use actions/cache or actions/upload to very easily transfer those to a separate job that updates the actual executables file in ORAS.

Since we'd already have the bottle manifest available, we could probably skip the ruby command and just use bash's sed and sort.

[Rylan12]

We should include the delete-old-versions job as well here IMO

https://github.com/Homebrew/brew/blob/main/.github/workflows/command-not-found-db-update.yml#L81-L94

[ooye-sanket]

@Rylan12 Thanks! I'll add the delete-old-versions job. Should I model it exactly after the existing job in command-not-found-db-update.yml#L81-94, or adapt it to run only for the changed formulae?

[MikeMcQuaid]

Instead of having this run as its own job, what if we tack this on to the publish-commit-bottles.yml job. That job already runs pr-pull to download the bottles, so I wonder if we could use actions/cache or actions/upload to very easily transfer those to a separate job that updates the actual executables file in ORAS.

Agreed with putting in an existing job.

I don't feel strongly about whether it's Ruby or Bash. Unless the Bash is very very simple Ruby is probably preferable.

[Rylan12]

@Rylan12 Thanks! I'll add the delete-old-versions job. Should I model it exactly after the existing job in command-not-found-db-update.yml#L81-94, or adapt it to run only for the changed formulae?

I think it only needs to run if the executables file actually gets an update pushed to github packages, but it should run every time that happens