`brew livecheck`

Команда brew livecheck находит самую новую версию программного обеспечения формулы или кега, проверяя upstream. Livecheck имеет стратегии для определения версий из различных источников, таких как репозитории Git, веб-сайты и т. д.

Поведение

Когда livecheck не получает инструкций о том, как проверять версии upstream, он по умолчанию выполняет следующие действия:

Для формул: собирает head, stable, и homepage URL-адреса в указанном порядке. Для кегов: собирает url и homepage URL-адреса в указанном порядке.
Определяет, применимы ли какие-либо стратегии к первому URL-адресу. Если нет, пробует следующий URL-адрес.
Если стратегия применима, использует её для проверки наличия новых версий.
Возвращает самую новую версию (или ошибку, если версии не удалось найти по доступным URL-адресам).

Иногда необходимо переопределить это поведение по умолчанию, чтобы создать работоспособную проверку. Если источник не предоставляет самую новую версию, нужно проверить другой. Если livecheck некорректно сопоставляет текст версии, необходимо указать соответствующий regex или strategy блок.

Это можно сделать, добавив livecheck блок в формулу/кег. Для получения дополнительной информации об имеющихся методах, пожалуйста, обратитесь к документации класса Livecheck.

Создание проверки

Используйте вывод отладки, чтобы понять ситуацию. brew livecheck --debug <formula>|<cask> предоставляет информацию о том, какие URL-адреса пытается использовать livecheck, какие стратегии применимы, сопоставленные версии и т. д.
Изучите доступные источники, чтобы выбрать URL-адрес. Попробуйте удалить имя файла из stable/url, чтобы увидеть, является ли это страницей списка каталога. Если это не работает, попробуйте найти страницу, которая ссылается на файл (например, страницу загрузки). Если найти самую новую версию на веб-сайте невозможно, попробуйте проверить другие источники из формулы/кега. При необходимости, поищите другие источники вне формулы/кега.
Создайте regex, если это необходимо. Если проверка работает без regex и не будет от неё выиграна, обычно достаточно его опустить. Более подробную информацию о создании regex можно найти в разделе рекомендации по regex.

Общие рекомендации

Используйте strategy только когда это необходимо. Например, если livecheck уже использует Git для URL-адреса, использование strategy :git не требуется. Однако, если Git применим к URL-адресу, но нам нужно использовать PageMatch, необходимо указать strategy :page_match.
Используйте стратегию GithubLatest только тогда, когда это необходимо и правильно. github.com ограничивает скорость запросов, и мы стараемся минимизировать использование этой стратегии, чтобы избежать достижения лимита скорости на CI или при использовании brew livecheck --tap на больших тапах (например, homebrew/core). Стратегия Git часто достаточна, и нам нужно использовать GithubLatest только в том случае, если «последняя» версия отличается от самой новой версии из тегов.

Примеры блоков `livecheck`

Следующие примеры охватывают ряд шаблонов, с которыми вы можете столкнуться. Они предназначены для иллюстрации и могут быть легко адаптированы.

В случае сомнений, начните с одного из этих примеров, а не копируйте livecheck блок из случайной формулы/кега.

Имена файлов

При сопоставлении версии из имени файла на странице HTML мы часто ограничиваем соответствие атрибутами href. href=.*? будет соответствовать открывающему разделителю (", ') а также любой части URL-адреса перед именем файла.

livecheck do
  url "https://www.example.com/downloads/"
  regex(/href=.*?example[._-]v?(\d+(?:\.\d+)+)\.t/i)
end

Иногда это делается более явно, чтобы исключить нежелательные соответствия. URL-адреса с предшествующим путем могут использовать href=.*?/, а другие могут использовать href=["']?. Например, это необходимо, когда на странице также есть нежелательные файлы с более длинным префиксом (another-example-1.2.tar.gz).

Каталоги версий

При проверке страницы списка каталогов иногда файлы разделены по каталогам версий (например, 1.2.3/). В этом случае необходимо определить версии по именам каталогов.

livecheck do
  url "https://www.example.com/releases/example/"
  regex(%r{href=["']?v?(\d+(?:\.\d+)+)/?["' >]}i)
end

Теги Git

Когда URL stable использует стратегию Git, следующий пример будет соответствовать только тегам, таким как 1.2/v1.2, и т. д.

livecheck do
  url :stable
  regex(/^v?(\d+(?:\.\d+)+)$/i)
end

Если теги включают имя программного обеспечения в качестве префикса (например, example-1.2.3), легко соответствующим образом изменить regex: /^example[._-]v?(\d+(?:\.\d+)+)$/i

Ссылки на формулу/кег

Формула/кег может использовать ту же проверку, что и другая, используя formula или cask.

livecheck do
  formula "another-formula"
end

Ссылки на формулу/кег должны находиться в одном тапе, так как ссылка на формулу/кег из другого тапа вызовет ошибку, если пользователь их не затаил.

Блоки `strategy`

Если для преобразования формата версии upstream необходимо использовать формат формулы/кега, можно использовать блок strategy вместо regex.

Блок стратегии `PageMatch` `strategy`

В примере ниже мы преобразуем формат даты, например 2020-01-01, в 20200101.

livecheck do
  url :homepage
  strategy :page_match do |page|
    page.scan(/href=.*?example[._-]v?(\d{4}-\d{2}-\d{2})\.t/i)
        .map { |match| match&.first&.gsub(/\D/, "") }
  end
end

Стиль блока стратегии PageMatch strategy здесь также применим к любой стратегии, которая использует PageMatch внутри.

Блок стратегии `Git` `strategy`

Блок strategy для Git немного отличается, так как блок получает массив строк тегов вместо строки содержимого страницы. Похоже на пример PageMatch, это преобразование тегов с форматом даты, например 2020-01-01, в 20200101.

livecheck do
  url :stable
  strategy :git do |tags|
    tags.map { |tag| tag[/^(\d{4}-\d{2}-\d{2})$/i, 1]&.gsub(/\D/, "") }.compact
  end
end

Блок стратегии `Sparkle` `strategy`

Блок strategy для Sparkle получает item, у которого есть методы для short_version, version, url и title.

Шаблон по умолчанию для стратегии Sparkle — "#{item.short_version},#{item.version}", если оба установлены. В примере ниже url также включает идентификатор загрузки, который необходим:

livecheck do
  url "https://www.example.com/example.xml"
  strategy :sparkle do |item|
    "#{item.short_version},#{item.version}:#{item.url[%r{/(\d+)/[^/]+\.zip}i, 1]}"
  end
end

`skip`

Livecheck автоматически пропускает некоторые формулы/кеги по ряду причин (устаревшие, отключенные, прекращённые и т. д.). Однако в редких случаях нам нужно использовать блок livecheck для ручного пропуска. Метод skip принимает строку с очень кратким объяснением причины пропуска.

livecheck do
  skip "No version information available"
end

`brew livecheck`

Поведение

Создание проверки

Общие рекомендации

Рекомендации по URL-адресам

Рекомендации по regex

Примеры блоков `livecheck`

Имена файлов

Каталоги версий

Теги Git

Ссылки на формулу/кег

Блоки `strategy`

Блок стратегии `PageMatch` `strategy`

Блок стратегии `Git` `strategy`

Блок стратегии `Sparkle` `strategy`

`skip`

brew livecheck

Поведение

Создание проверки

Общие рекомендации

Рекомендации по URL-адресам

Рекомендации по regex

Примеры блоков livecheck

Имена файлов

Каталоги версий

Теги Git

Ссылки на формулу/кег

Блоки strategy

Блок стратегии PageMatch strategy

Блок стратегии Git strategy

Блок стратегии Sparkle strategy

skip

`brew livecheck`

Примеры блоков `livecheck`

Блоки `strategy`

Блок стратегии `PageMatch` `strategy`

Блок стратегии `Git` `strategy`

Блок стратегии `Sparkle` `strategy`

`skip`