You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@woodruffw@alex Would love to help move this along somehow if I could. The two ways that jump out to me (based on other Homebrew ecosystem things) are:
have the bot create PRs that a human eyeballs and merges instead of pushing direct to main
either this repository or another one instead deploys these JSON files to GitHub Pages which brew-pip-audit then consumes instead of needing these files committed into this repository
There may also be other approaches here that I don't currently see (e.g. plain old GitHub Actions caching of this data). I'm happy to help move forwards whatever approach you think makes most sense here. Right now this is one of the 2 remaining repos that don't have human review for all changes and I'd love to fix that in the next 2-3 months 😁
have the bot create PRs that a human eyeballs and merges instead of pushing direct to main
I'm a fan of this 🙂 -- I think nothing about our current flow would be badly disturbed/disrupted by changing to PRs over pushing directly.
I'm curious if @alex has strong feelings either way; the only "downside" to the PR flow is that a human has to merge it each day (or whatever window we choose), but I don't mind being the one to do that.
I think having a human review the requirements.txt + audit files we produce every day would not be a good use of time/energy. There's limited meaningful review that could occur beyond "yup, that sure is a requirements.txt file", so I believe any review would be nothing beyond a rubber stamp.
If the goal is to get branch protection on main, I think it'd be far more sensible to simply have all the data lives in a different branch/repo/datastore.
Yeah, it would be just a rubber-stamp effectively (there's also the annoying bit where machine-generated PRs don't trigger CI automatically unless they come from a PAT or app, although in this context I suppose we don't have that issue thanks to @BrewTestBot).
I suppose having it be a JSON or whatever dump on GitHub Pages would be the best of both worlds then -- no protection bypasses and no rubber-stamp for data-only changes.
@woodruffw are you game to take this on? anything I can do to help? I'd suggest looking at the formulae.brew.sh and rubydoc.brew.sh repos for Jekyll inspiration.
Activity
MikeMcQuaid commentedon May 28, 2024
Related issue which may provide inspiration: Homebrew/brew#17379
MikeMcQuaid commentedon May 28, 2024
For example, in this case the regularly regenerated files could instead be deployed to GitHub Pages instead.
MikeMcQuaid commentedon Jun 20, 2025
@woodruffw @alex Would love to help move this along somehow if I could. The two ways that jump out to me (based on other Homebrew ecosystem things) are:
main
brew-pip-audit
then consumes instead of needing these files committed into this repositoryThere may also be other approaches here that I don't currently see (e.g. plain old GitHub Actions caching of this data). I'm happy to help move forwards whatever approach you think makes most sense here. Right now this is one of the 2 remaining repos that don't have human review for all changes and I'd love to fix that in the next 2-3 months 😁
woodruffw commentedon Jun 20, 2025
I'm a fan of this 🙂 -- I think nothing about our current flow would be badly disturbed/disrupted by changing to PRs over pushing directly.
I'm curious if @alex has strong feelings either way; the only "downside" to the PR flow is that a human has to merge it each day (or whatever window we choose), but I don't mind being the one to do that.
alex commentedon Jun 20, 2025
I think having a human review the requirements.txt + audit files we produce every day would not be a good use of time/energy. There's limited meaningful review that could occur beyond "yup, that sure is a requirements.txt file", so I believe any review would be nothing beyond a rubber stamp.
If the goal is to get branch protection on main, I think it'd be far more sensible to simply have all the data lives in a different branch/repo/datastore.
woodruffw commentedon Jun 20, 2025
Yeah, it would be just a rubber-stamp effectively (there's also the annoying bit where machine-generated PRs don't trigger CI automatically unless they come from a PAT or app, although in this context I suppose we don't have that issue thanks to @BrewTestBot).
I suppose having it be a JSON or whatever dump on GitHub Pages would be the best of both worlds then -- no protection bypasses and no rubber-stamp for data-only changes.
alex commentedon Jun 20, 2025
Yes. (It'd also give us a place to put some of the tables that we currently put in GHA output)
MikeMcQuaid commentedon Jun 20, 2025
Ok, thanks!
@woodruffw are you game to take this on? anything I can do to help? I'd suggest looking at the formulae.brew.sh and rubydoc.brew.sh repos for Jekyll inspiration.
woodruffw commentedon Jun 20, 2025
Yep, I can do it this weekend/early next week most likely 🙂
MikeMcQuaid commentedon Jun 20, 2025
Thanks for input here too @alex, very helpful ❤
woodruffw commentedon Jun 22, 2025
Working on this in #210!
woodruffw commentedon Jun 24, 2025
#210 completes the machinery of this -- reopening so that this can be fully closed once the repo protections are actually enabled 🙂
MikeMcQuaid commentedon Jun 24, 2025
Done, thanks @woodruffw!