Add source-ref input to build devbox from source

[gcurtis]

Its sometimes useful to install a version of devbox that hasn't been tagged for a release yet. Add a source-ref input to make the action clone and build devbox from source instead of using the installer script.

This is intended for development and debugging. It should not be used in production workflows.

Example:

- uses: jetify-com/devbox-install-action@main
  with:
    source-ref: main

The cloned devbox repository and the built binary are placed in a subdirectory in the GitHub workspace.

If Go is already in the PATH, the action won't install it again. This gives the caller an opportunity to install Go themselves and specify the Go version or caching options.

For now, caching the CLI is always disabled when building from source.

[LucilleH]

@gcurtis I'm not sure if this is a good idea, or if we want to encourage such behavior. What is your use case?

[gcurtis]

@LucilleH there are a couple of places where this would be handy:

• Our own CI workflows where we want to be using features or fixes that are only on main or in a PR.
• Users that are testing new features that haven't been released yet and need bug fixes.

In both cases needing to perform a prerelease is cumbersome. Some of our workflows end up building from source manually to work around it.

[LucilleH]

@gcurtis how about the github action checks for existing devbox binary installed in the instance before downloading the CLI - In a sense, if users want to install a custom devbox CLI built from source, they can perform that step before calling this action, with the binary made available under ~/.local/bin/devbox.

WDYT? Would that work?

[mikeland73]

I think this is is cool and would definitely be useful for us (especially for testing new features). Currently whenever we want to test a new feature we have to switch from using the action to building from source.

I do agree that outside of devbox development, not sure if there would be wide use of a feature like this.

Building on @LucilleH's suggestion, maybe in the devbox repo we build a custom action action that wraps this action and replaces the devbox binary with whatever is built in that PR? That would have the advantage of building from the PR instead of main so we can test changes in the PR itself. Then we can can use that action instead?

[gcurtis]

Does the following sound good?

1. Update this action to skip installing devbox if it's already found in the PATH (and print a message saying it's doing that).
2. Move these changes into a separate action in devbox/.github/actions/devbox-install-source.yaml (name TBD). That action calls this action after building and installing a devbox ref from source.

[LucilleH]

Does the following sound good?

1. Update this action to skip installing devbox if it's already found in the PATH (and print a message saying it's doing that).

Yes perfecto.

2. Move these changes into a separate action in devbox/.github/actions/devbox-install-source.yaml (name TBD). That action calls this action after building and installing a devbox ref from source.

This devbox/.github/actions/devbox-install-source.yaml is referring to the devbox repo? (if so, LGTM)

[gcurtis]

@LucilleH yeah, I'd put it in the devbox repo.