Generalize boot.sh to support running any ref

[rmacklin]

This will enable running not only the master and stable branches ¹, but also unmerged commits, for easier testing, e.g.

export OMAKUB_REF=2f1544548d8709f61e9e6aac5e222b000770898b
wget -qO- "https://raw.githubusercontent.com/basecamp/omakub/${OMAKUB_REF}/boot.sh" | bash

The hope is this would provide a good way to have folks test things like #29 before they've been merged.

Additionally, together with:

• Update install scripts omakub-site#4

it removes the need for a separate boot-dev.sh script (which was nearly identical to boot.sh).

Footnotes

1. Note: stable and master will still be runnable via the existing wget -qO- https://omakub.org/install | bash and wget -qO- https://omakub.org/install-dev | bash commands, respectively. No workflow changes needed for those two common cases! ↩

[rmacklin]

@dhh Curious to get your thoughts on this. I just updated the PR description to clarify that this would not take away the common case of running
wget -qO- https://omakub.org/install | bash or
wget -qO- https://omakub.org/install-dev | bash.

The goal is simply to support a similar mechanism for testing other changes that aren't merged to master or stable (like the work-in-progress changes to add ARM support, as one example where I see this being useful). And a little side-benefit is it obviates the need to maintain a separate, nearly identical boot-dev.sh script.

That said, let me know if you have any objections to this, so I can either try to address them or abort and close the PRs.

[dhh]

How would you be able to test something that isn't on master through this? Wouldn't those PRs be on a separate cloned repo URL?

[rmacklin]

In GitHub, fork repositories share the same underlying git data, i.e. commits from a fork can be viewed/fetched in the base repository. Branches and tags are scoped to individual repositories, but the underlying commits aren't - it's been that way since forks were introduced, and is foundational to the GitHub repository "network". So we're just leveraging that here.

[rmacklin]

I should clarify that in order to test a PR like #29 or #227 using this method, the PR would have to be rebased or have master merged into it. Any new PRs branched off master will be good to go.

[dhh]

This is breaking the update script. Since you're no longer directly on the stable branch. Can you have a look at how we might fix this? And also how we might fix it for folks who've installed this in a way where update now won't run?

[rmacklin]

I've opened #240 which I think should address this going forward. Unfortunately, I think folks who did a first-run install in v1.1.2 would have to manually run cd $OMAKUB_PATH && git checkout stable before updating omakub...