Automatically install apps from GitHub releases

As Go and Rust become more widespread, more and more programs appear that consist of a single binary without any non-standard dependencies, and which we install manually by downloading a release from GitHub: either because the application is not yet in your distribution, or because we simply want to always have the latest version, and not wait for it to be pulled into the distribution.

Installing (and especially updating) such applications manually is a thankless task, especially when their number becomes more than one or two – and you want some automation. I have about a dozen such programs, and for quite a long time I used various knee-jerk scripts like this to keep them up to date. But a bash script is still somehow not serious, and therefore I always wanted something more manageable in the form of a normal application. I was unable to find something ready-made that would satisfy all my needs right away – so some time ago I decided to follow my favorite path and write my own application for this specific task.

Binup

A couple of weeks of coding in the evenings – and the utility was born Binup. I recently released version 1.0.0 and completely switched to it from my scripts. I will be glad if the resulting tool will be useful to someone other than me.

Here's how it works: you create a configuration file ~/.config/binup/config.yaml with approximately the following content, in which you describe a specific application (how to find it on GitHub):

tools:
  binup:
    project: KonishchevDmitry/binup

… you launch binup install or binup upgrade – and Tula installs or updates the applications you specified.

Works binup It's pretty simple: it doesn't store any information about installed applications anywhere, but instead, when launched, it looks at their current status: if the required binary isn't there, it installs it; if it is, it tries to launch the application with --versionto determine the current version of the application and compare it with the latest release on GitHub. If the version could not be determined (for example, the program may not support the flag at all --version), That binup is based on the file modification time, which, when installing the application, is set equal to the release modification time.

Configuration

Here is an example configuration file with all currently available options:

# Path where to install the binaries (the default is ~/.local/bin)
path: /usr/local/bin

tools:
  # Binary name
  prometheus:
    # GitHub project name
    project: prometheus/prometheus

    # Changelog URL (will be printed on app upgrade)
    changelog: https://github.com/prometheus/prometheus/blob/main/CHANGELOG.md

    # Release archive pattern:
    # * By default shell-like glob matching is used (https://docs.rs/globset/latest/globset/#syntax)
    # * Pattern started with '~' is treated as regular expression (https://docs.rs/regex/latest/regex/#syntax)
    #
    # If it's not specified, the archive will be chosen automatically according to target platform.
    release_matcher: prometheus-*.linux-amd64.tar.gz

    # Binary path to look for inside the release archive. If it's not specified, the tool will try to find it automatically.
    binary_matcher: "*/prometheus"

    # Post-install script
    post: systemctl restart prometheus

# If you have a lot of tools, you may hit GitHub API rate limits for anonymous requests at some moment.
# So it's recommended to obtain GitHub token (https://github.com/settings/tokens) and specify it here.
# No permissions are required for the token – it's needed just to make API requests non-anonymous.
github:
  token: $token

Further development

Develop it into some kind of full-fledged package manager like Homebrew I don’t exactly plan to, but within the framework of solving the above-described problem – quite possible.

So far, the only obvious potential feature that I see is GitLab support, if such a need arises (I personally don’t have a single application with it yet). Right now it covers all my needs, but it’s quite possible that new ones will arise during use – and then I’ll cover them too.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *