Add Brioche nightly support

[jaudiger]

This PR adds the ability to set the Brioche channel to mimic what we can already do with the official Brioche install script (which has been included in this PR: brioche-dev/brioche.dev#49).

Only two values will be accepted:

• stable
• nightly

If nightly is set, it won't be possible to override the Brioche version used, thus an error will be produced if both version and channel fields are present.

Bonus point: with this PR, it'll now be possible to use this GitHub action on ARM GitHub runner when using the nightly channel !

[jaudiger]

@kylewlacy I put this PR in draft, since I would like first to run the tests (see this comment for context: #10 (comment)), I think we need to tweak the settings of this GitHub repository

[kylewlacy]

Suggested change

	- runs-on: ubuntu-latest
	channel: stable
	- runs-on: ubuntu-latest
	channel: nightly
	- runs-on: ubuntu-latest-arm
	channel: stable
	- runs-on: ubuntu-latest-arm
	channel: nightly
	- runs-on: ubuntu-24.04
	channel: stable
	- runs-on: ubuntu-24.04
	channel: nightly
	- runs-on: ubuntu-24.04-arm
	channel: stable
	- runs-on: ubuntu-24.04-arm
	channel: nightly

Just found out that GitHub Actions doesn't seem to support ubuntu-latest-arm (and they don't plan to add it). I think that's kinda annoying... so it seems sensible to just use a specific Ubuntu version for each of these jobs (we could keep using ubuntu-latest but to keep it symmetric I'd lean towards keeping all of them pinned together)

[jaudiger]

Ok, I updated it in c4060fa. And I took the opportunity to re-add ubuntu-latest in the matrix of the smoke test

[kylewlacy]

Minor tweak to show the separation between version and channel in the README

Suggested change

	# version: "latest" # Optional
	# version: "v0.1.5" # Optional
	# channel: "latest" # Optional

[jaudiger]

Kinda done, since it's now removed

[kylewlacy]

@jaudiger One idea I started thinking about... what if we got rid of channel and just used version as the key for both settings? channel=nightly and version are mutually exclusive anyway. So it seems like it should always be pretty easy to tell them apart (can't imagine we'll have too many channels besides a few common terms: stable, beta, nightly, prerelease, lts), and seems like a small tripping point to confuse the two

Again just an idea, so I'm fine with keeping them separate if you think it's better this way!

[jaudiger]

Well, there is pro and cons depending on the chosen options:

• Keeping channel / version:
  • Pros:
    • Clarity about the purpose of each field
    • Validation is easier for us
    • Error reporting will directly point one field
  • Cons:
    • Conflict between version and channel -> the current issue
• Merging channel / version -> ref or another thing or just keep version ? :
  • Pros:
    • One field to manage
    • More compact, and thus, easier to use
  • Cons:
    • Harder to validate
    • Format of the field will be harder to find (even if the syntax channel@version or version@channel should be pretty common for most of us)
    • Backward compatibility with current GitHub Action released ?

I would prefer the use of two field since it's clearer to know what fields mean, but I'm not against merging them. Both possibilities are valid and quite common.

But I tend to agree that if one day, we want to extend the GitHub Action to also choose the nightly version, we cannot keep the field version as it:

jobs:
  setup-brioche:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v5

      - name: Setup Brioche
        uses: brioche-dev/setup-brioche@v1
        with:
          channel: 'nightly'
          version: '2025-10-02' # It's kinda weird to have a date here, and it could confuse the end user, since this version does not really exist

So, we could either rename version to something more generic like ref, target, etc. Or just merge both fields:

jobs:
  setup-brioche:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v5

      - name: Setup Brioche
        uses: brioche-dev/setup-brioche@v1
        with:
          ref: 'nightly@2025-10-02'

Versus:

jobs:
  setup-brioche:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v5

      - name: Setup Brioche
        uses: brioche-dev/setup-brioche@v1
        with:
          channel: 'nightly'
          ref: '2025-10-02'

Versus:

jobs:
  setup-brioche:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v5

      - name: Setup Brioche
        uses: brioche-dev/setup-brioche@v1
        with:
          version: 'nightly@2025-10-02' # It could do the trick, if version has a syntax well defined, but what about backward compatibility ?

[kylewlacy]

@jaudiger That's a lot of good points! But I wanted to go a bit more depth on how I was thinking about it more concretely... my take on combining them would be to follow a model pretty similar to Rust's channels + versions (basically the things you can put in the channel field in rust-toolchain.toml):

1. Release channels: stable, nightly (maybe more in the future like beta)
2. Specific stable version: v0.1.5
3. Major or major+minor version: v0.1, v0
4. Specific prerelease versions: v0.1.6-nightly.20251002

So that means we'd never need something like [email protected] or similar-- v0.1 should always imply stable while unstable ones would use the normal semver-style prerelease syntax.

Initial support could just cover (1) and (2), meaning the script would check for stable and nightly as channels, otherwise assume it's a version (and ideally also validating it starts with v followed by a semver version).

In the future, I was thinking we could cover all 4 situations generically, so this script wouldn't need to care about channels vs. versions. Instead they would all get routed to a URL like https://releases.brioche.dev/channels/{any_of_the_strings_above}/latest-version.txt, which then returns a specific version number that can then be downloaded in a consistent way.

As for the name of the combined field, I personally like how version sounds over channel, but there's of course precedent with channel from Rust, so I would be fine with either. tag and ref I'm not against, but to me already feel pretty overloaded from git

---

Normally I'd be more lax about just picking one and trying it out, but since setup-brioche is already v1.x, I want to try and preserve backwards compatibility like you mentioned! I think the scheme I outlined above would be backwards compatible with the current action, right? But in any case, I want to make sure we're on the same page first. Let me know if you're still leaning towards separate fields and we can make a decision from there

[kylewlacy]

Also, @asheliahut made a good point that it’s pretty common convention for “setup” actions to just use a single field for both purposes: actions/setup-node, shivammathur/setup-php, hashicorp/setup-terraform, pnpm/action-setup, etc. all support a channel name for the version (or {toolname}-version) input. It seems to be the most common way to handle channels by far, so that makes me lean even more towards just having a single field named version

[jaudiger]

@kylewlacy @asheliahut Fair enough, you both convinced me to merge both fields into a single one. I just pushed a commit in this direction, taking in account what you suggested @kylewlacy

[asheliahut]

Yeah, sorry I haven't directly said something on this til now, but yeah I definitely looked at how all the big named and supported actions were doing this back when I set out to make this action. I wanted to make sure it was following what most people would be used to in order to facilitate easy adoption.

[jaudiger]

Sure, we should follow how things are done usually, I understand. Thanks for the insights @asheliahut.

I finally completed this PR, you can have another round of review whenever you want

[kylewlacy]

LGTM 👍

This should be a big win for our own workflows too!

[jaudiger]

This should be a big win for our own workflows too!

Once a new release of the GitHub action is available, I’ll make sure to open the PRs to update our workflows 🚀