Support installation on alternative platforms #63
Conversation
|
@swift-server-bot test install please |
|
@swift-server-bot test install please |
| esac | ||
| } | ||
|
|
||
| verify_getopt_install () { |
There was a problem hiding this comment.
getopt is a super useful tool for parsing CLI options in bash scripts. It's included in the util-linux package, but in practice basically every Linux distro comes with it pre-installed...except Amazon Linux 2. The alternatives are manual parsing (which gets tricky with stuff like -pubuntu20.04, -p ubuntu20.04, --platform=ubuntu20.04, and --platform ubuntu20.04) or using the shell builtin getopts, which doesn't support long names like --platform. Given that we already require curl to be installed, it didn't seem like a huge problem to add an additional dependency on util-linux.
| return "$?" | ||
| } | ||
|
|
||
| SWIFTLY_INSTALL_VERSION="0.2.0" |
There was a problem hiding this comment.
the swiftly-install version doesn't need to be tied to swiftly's actual version imo, since we may make updates to it like this independent of changes to swiftly.
There was a problem hiding this comment.
We need to keep the tags on the repo in sync though. A new version of the script should be tagged a release, otherwise managing versions of the script is going to be painful.
There was a problem hiding this comment.
Yeah, I agree we ought to tag releases of swiftly-install, though we shouldn't mark them as a full on "Releases" in the GitHub sense of things, since then we'd need the install script to disambiguate when trying to download binaries.
| return "$?" | ||
| } | ||
|
|
||
| SWIFTLY_INSTALL_VERSION="0.2.0" |
There was a problem hiding this comment.
We need to keep the tags on the repo in sync though. A new version of the script should be tagged a release, otherwise managing versions of the script is going to be painful.
2 participants
Implements #60