The gitlab-cli feature fails to install when version resolves to a glab release ≥ 1.100.0 (including latest, currently 1.106.0), because install.sh uses bash's string comparison operator to decide which asset-naming scheme to use:
if [[ "${CLI_VERSION}" < "1.47.0" ]]; then
arch="${arch:-$(uname -m)}";
else
arch="${arch:-$(dpkg --print-architecture | awk -F'-' '{print $NF}')}";
os="${os,,}";
fi[[ ... < ... ]] compares strings lexicographically, not as version numbers. For CLI_VERSION=1.106.0, comparing against "1.47.0" character-by-character hits '1' < '4' at the third character, so the expression evaluates true even though 106 > 47. This sends the script down the old branch, producing filenames like glab_1.106.0_Linux_x86_64.deb, which no longer exists on GitLab's release server (current assets use glab_1.106.0_linux_amd64.deb). The install then fails with a 404.
Repro:
$ echo '[[ "1.106.0" < "1.47.0" ]] && echo old || echo new' | bash
old
Suggested fix: Replace the string comparison with a proper version comparison, e.g. sort -V or dpkg --compare-versions "${CLI_VERSION}" lt 1.47.0.
The
gitlab-clifeature fails to install whenversionresolves to a glab release ≥ 1.100.0 (includinglatest, currently 1.106.0), becauseinstall.shuses bash's string comparison operator to decide which asset-naming scheme to use:[[ ... < ... ]]compares strings lexicographically, not as version numbers. ForCLI_VERSION=1.106.0, comparing against"1.47.0"character-by-character hits'1' < '4'at the third character, so the expression evaluatestrueeven though106 > 47. This sends the script down the old branch, producing filenames likeglab_1.106.0_Linux_x86_64.deb, which no longer exists on GitLab's release server (current assets useglab_1.106.0_linux_amd64.deb). The install then fails with a 404.Repro:
Suggested fix: Replace the string comparison with a proper version comparison, e.g.
sort -Vordpkg --compare-versions "${CLI_VERSION}" lt 1.47.0.