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
In most cases, updating packages in the brioche-packages repo is fairly easy, but it's pretty dry work: look up the package, figure out the latest version number, update the value for project.version, test locally, then open a PR.
By design, this process should be pretty easy to automate. To auto-update a package, all we need to do is figure out how to update project.version properly-- the rest can be handled by a CI pipeline (say, a GitHub Actions workflow running on a schedule, or maybe something based on Rennovate, etc.).
So, here's a design that could work as an MVP for auto-updating packages:
The Brioche project for a package exports an autoUpdate function. When run, it should "return" a new value for the project export. This function could use the GitHub /releases/latest API, or any other means of determining the latest version.
The subcommand brioche auto-update runs this autoUpdate function.
It uses the return value to update the project.bri code-- replacing the old project export with the value from autoUpdate.
It then loads the project and updates any lockfiles.
For (1), the trickiest part of this work is deciding how autoUpdate should "return" the new value. If we literally made it return a JavaScript value, that would be pretty hard to fit with Brioche's current data model: if you tried to bake a process recipe, then the result would be permanently cached!
For an MVP, the easiest option would be for autoUpdate to return a runnable. Here's a simple example based on the ripgrep package:
To get the new project value, Brioche would bake the autoUpdate recipe, run the brioche-run executable from the artifact root, then get the new project value from the process's output (stdout in the above example).
The text was updated successfully, but these errors were encountered:
In most cases, updating packages in the
brioche-packages
repo is fairly easy, but it's pretty dry work: look up the package, figure out the latest version number, update the value forproject.version
, test locally, then open a PR.By design, this process should be pretty easy to automate. To auto-update a package, all we need to do is figure out how to update
project.version
properly-- the rest can be handled by a CI pipeline (say, a GitHub Actions workflow running on a schedule, or maybe something based on Rennovate, etc.).So, here's a design that could work as an MVP for auto-updating packages:
autoUpdate
function. When run, it should "return" a new value for theproject
export. This function could use the GitHub/releases/latest
API, or any other means of determining the latest version.brioche auto-update
runs thisautoUpdate
function.project.bri
code-- replacing the oldproject
export with the value fromautoUpdate
.For (1), the trickiest part of this work is deciding how
autoUpdate
should "return" the new value. If we literally made it return a JavaScript value, that would be pretty hard to fit with Brioche's current data model: if you tried to bake a process recipe, then the result would be permanently cached!For an MVP, the easiest option would be for
autoUpdate
to return a runnable. Here's a simple example based on theripgrep
package:To get the new
project
value, Brioche would bake theautoUpdate
recipe, run thebrioche-run
executable from the artifact root, then get the new project value from the process's output (stdout in the above example).The text was updated successfully, but these errors were encountered: