CLI приложения #24. Распространяем приложение через GitHub Releases

В предыдущих постах мы разобрались, как собрать CLI-приложение в исполняемый файл и как распространять его в виде .NET tool. Но что делать, если мы хотим поделиться программой с пользователями, у которых вообще нет .NET? Или просто не хочется заставлять их устанавливать дополнительные инструменты? Можно, конечно, отправить архив с программой. Но как тогда распространять обновления, хранить предыдущие версии и предоставлять сборки для разных операционных систем?

Для этого можно использовать GitHub Releases.

Это механизм публикации версий проекта на GitHub. К каждому релизу можно прикрепить готовые исполняемые файлы, архивы, инструкции и список изменений.

Подготовим сборки#

Вспомним self-contained и single-file из 22-й части. Именно они нам сейчас пригодятся.

Например, соберём приложение для Windows:

dotnet publish -c Release -r win-x64 --self-contained true -p:PublishSingleFile=true -o ./publish/win-x64

Для Linux:

dotnet publish -c Release -r linux-x64 --self-contained true -p:PublishSingleFile=true -o ./publish/linux-x64

И для macOS на Apple Silicon:

dotnet publish -c Release -r osx-arm64 --self-contained true -p:PublishSingleFile=true -o ./publish/osx-arm64

В результате получим три сборки для разных платформ.

Здесь есть нюанс: single-file не гарантирует, что в папке будет строго один файл. Некоторые нативные зависимости могут остаться рядом. Поэтому перед упаковкой обязательно проверяем содержимое каталога. Кроме того, сборка под другую ОС ещё не означает, что приложение на ней действительно работает. В идеале каждую сборку нужно проверить на целевой платформе.

Упаковываем результат#

Создадим архив для каждой платформы.

Например, в PowerShell для Windows:

Compress-Archive -Path ./publish/win-x64/* -DestinationPath ./myapp-v1.0.0-win-x64.zip

Аналогично подготовим архивы для Linux и macOS.

В итоге у нас будет примерно такой набор:

myapp-v1.0.0-win-x64.zip
myapp-v1.0.0-linux-x64.zip
myapp-v1.0.0-osx-arm64.zip

Для Unix-платформ часто удобнее использовать tar.gz: такой архив сохраняет права доступа к исполняемым файлам.

Создаём релиз#

Теперь переходим в репозиторий на GitHub, открываем раздел Releases и выбираем Draft a new release. Нам предложат указать тег, например v1.0.0. Тег в Git — это ссылка на определённое состояние репозитория. Таким образом мы связываем опубликованную версию приложения с конкретным состоянием исходного кода.
Далее указываем название релиза, описание изменений и прикрепляем подготовленные архивы.

Например:

MyApp v1.0.0

Первый публичный релиз.

Добавлено:
- обработка команд и аргументов;
- вывод справки;
- поддержка Windows, Linux и macOS.

Разумеется, перечислять нужно только те возможности и платформы, которые действительно реализованы и проверены.

Нажимаем Publish release, и готово!

Теперь пользователи смогут открыть страницу релиза, выбрать архив для своей системы, скачать его и запустить приложение.

А как устанавливать?#

Пока всё довольно просто: пользователь скачивает архив, распаковывает его в удобную папку и при необходимости добавляет эту папку в PATH.

На Windows это может быть, например:

C:\Tools\MyApp\

А на Linux:

~/.local/bin/

Если каталог уже находится в PATH, приложение можно запускать по имени, без полного пути. Правда, у такого способа есть недостатки. Пользователю приходится самостоятельно выбирать каталог, настраивать окружение, а при обновлении заменять файлы вручную. К тому же на macOS и Windows при запуске скачанных приложений могут сработать механизмы защиты системы, особенно если приложение не подписано.

Итого.#

Теперь мы можем распространять готовые версии приложения через GitHub, причём для разных операционных систем и без необходимости устанавливать .NET Runtime. Но пока это всё ещё архивы, с которыми пользователю приходится работать самостоятельно.
А хотелось бы, чтобы программа устанавливалась привычным способом: выбираем папку, нажимаем «Установить», а дальше всё происходит автоматически. И чтобы потом её можно было нормально обновить или удалить. Поэтому, в следующей части попробуем сделать такой установщик для Windows. Разберёмся, куда попадают файлы, зачем нужен реестр, как настраивается PATH и что происходит при удалении приложения.

В общем, сделаем всё как у взрослых программ. ))