Allow passing branch name to bootstrap.sh

[wp-davisona]

This ensures that it is possible to checkout a tag or branch and install from that tag using the same versioned files, for reliable repeatable builds.

e.g.

bootstrap.sh
will still install from the base url
https://raw.githubusercontent.com/getredash/redash/master/setup/ubuntu/files/
but

git checkout v0.9.2.b1536
bootstrap.sh v0.9.2.b1536

will install from the base url:
https://raw.githubusercontent.com/getredash/redash/v0.9.2.b1536/setup/ubuntu/files/postgres_apt.sh

[arikfr]

I'm not sure it's worth the hassle. The files it pulls are mainly configuration, which doesn't change much between versions.

Also it's confusing, as I would expect it to install the version specified, which it won't do. The installed version is controlled via the REDASH_VERSION env variable. So to really install b1536 you will need to type

REDASH_VERSION=v0.9.2.b1536 bootstrap.sh v0.9.2.b1536

If someone needs a reliable environment for an older version, I recommend using the relevant Docker image.

[wp-davisona]

We've had a couple of occasions where using a static base path has broken our builds. The first was when this path pointed at a docker branch which was deleted and then again when a broken nginx config was committed to master.

This doesn't break any existing behaviour as it still defaults to master and adds flexibility for those who would like to use configurations and scripts from a previously known working version or an experimental branch etc.

I've submitted this as a nice to have, but of course there may be some better method to this.

[arikfr]

Fair enough. How about then we use this parameter for the tarball path as well (when it's not master)?

[wp-davisona]

Hmm, maybe this would be better as an environment variable too, rather than a command line parameter. Keep it consistent.

Unfortunately, I'm not at a computer till next week, so I'll revisit this then.

[arikfr]

Env var sounds good to me, let's name it BRANCH and update the references in code to branch as well, to make sure people aren't confused.

[wp-davisona]

Ok, I went with REDASH_BRANCH instead of just BRANCH, to be consistent with REDASH_VERSION (but can go with BRANCH if you prefer)

This means a previous release (well, from the point this is merged onwards) can be installed reliably by running:

git checkout v0.9.2.b1536
env REDASH_BRANCH=v0.9.2.b1536 REDASH_VERSION=0.9.2.b1536 ./bootstrap.sh

Note that Branch includes the "v" while Version omits it. It would be possible to merge these variables as one, but then that would remove the flexibility of being able to specify an experimental feature branch based of a specific or current version etc.

Of course running bootstrap.sh on its own without any branch or version still behaves exactly as before.

I also moved the REDASH_VERSION declaration to the top of the bootstrap files as I noticed it defaults to a specific version that needs to be updated whenever there's a new release and this hadn't been done. With it up there at the top of the file it's more noticeable to anyone casually glancing through looking for reasons why they had an unexpected outcome to an installation.

Does this seem cleaner and easier to follow?

[arikfr]

Looking good. Thanks!