Open gcurtis opened 3 months ago
@gcurtis I'm not sure if this is a good idea, or if we want to encourage such behavior. What is your use case?
@LucilleH there are a couple of places where this would be handy:
main
or in a PR.In both cases needing to perform a prerelease is cumbersome. Some of our workflows end up building from source manually to work around it.
@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?
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?
Does the following sound good?
devbox/.github/actions/devbox-install-source.yaml
(name TBD). That action calls this action after building and installing a devbox ref from source.Does the following sound good?
- 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.
- 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)
@LucilleH yeah, I'd put it in the devbox repo.
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:
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.