-
Notifications
You must be signed in to change notification settings - Fork 1
Description
The script used in this action is extremely similar to the install script served via brioche.dev
, which is currently maintained in the brioche-dev/brioche.dev
website repo (permalink).
Rather than maintaining two different scripts and keeping them updated, we could instead refactor the setup-brioche
action to instead download and execute the installer via brioche.dev
-- basically just like anyone would do by hand. For GitHub Actions inputs, these would be translated to env vars passed to the install script.
Note
At the time of writing, the GitHub Actions workflow includes an extra option called install-apparmror
. For this setting (and any other GitHub Actions-specific settings in the future), we'll either want to make this setting an option in the main install script, or keep it as a specific feature in this action. For now, I think it makes sense to keep install-apparmor
as a GitHub Actions-specific feature (and we could always move it in the future).
There's precedent for other big GitHub Actions to just fetch and run another installer shell script. A few examples that do just call an installer:
(I did also find a few that don't call an external installer too, including shivammathur/setup-php
(installs via apt?), hashicorp/setup-terraform
(direct download), and oven-sh/setup-bun
(direct download via GitHub Releases))
From a supply-chain security perspective, I think some folks could be concerned about this approach-- but personally, since the installer is going to be downloading a binary to run from the same brioche.dev
domain anyway, it doesn't seem like a huge risk. If there's demand for it, we could also take some extra precautions too, like versioning the install script itself, or signing the install script