far-bisect: use GitHub releases as builds source

[johnd0e]

[shmuz]

Спасибо, буду смотреть. Только не удивляйтесь, если моя реакция будет порядка недели.

[johnd0e]

Только не удивляйтесь, если моя реакция будет порядка недели.

Это совсем не проблема. Как и то, что выбранное решение может вам не понравиться.

Например тем, что для работы требуется сторонняя утилита. Альтернативно: можно было бы обойтись модулем для парсинга JSON, и реализовать работу с апи самостоятельно. Минусы:

• Хоть это и не сложно реализовать, но это тоже время.
• Получить все релизы можно только используя реальный access token (который конечно же не стоит публиковать). gh.exe как-то обходится без, вероятно использует какой-то приватный. Без access token доступны только последние 1000 релизов (в билдах это меньше).
  • С другой стороны, на практике достаточно опубликовать список всех старых релизов, а для получения обновлений и 1000 хватит с головой.

[johnd0e]

Чего ещё не хватает в скрипте:

• возможности сохранять скачанные дистрибутивы. Сейчас даже если при выходе выбрать не удалять временные файлы, всё равно в следующий раз всё будет качаться повторно. А в идеале желателен некий общий знаменатель для локально хранимых билдов (Make_Local_Build_List), и скачиваемых в процессе работы (Make_Github_Build_List/Make_Web_Build_List), чтобы они не просто скачивались, а (опционально) складывались бы в архив для повторного использования.
• архивы с одним и тем же билдом могут отличаться, поскольку не каждое изменение меняет номер билда. Поэтому и существуют архивы с разными датами и хэшами. Сейчас просто выбирается самый свежий, а можно было бы тестировать вообще все.

Но это всё в идеале, и не факт что стоит усилий.

[johnd0e]

P.S. В плане выбора способа загрузки архивов

• Windows 10 содержит curl.exe
• С помощью Powershell тоже можно скачивать файлы

[shmuz]

Чего ещё не хватает в скрипте:

Это так, потенциал для улучшения есть немалый. Но как вы правильно заметили, это требует времени. Полагаю, что с добавлением ещё одного разработчика (вас), скрипт будет улучшен в разных аспектах.

[johnd0e]

...будет улучшен в разных аспектах.

Определённо все локальные улучшения, если таковые возникнут, я буду публиковать. Но не уверен что захочу трогать части, заточенные под вашу инфраструктуру, поскольку не вижу общей картины. Кое-что я временно закомментировал (06fe18e5eb08a1adb064e962690a11053f3f01f2), и для моего частного использования это годится, но в конце концов это надо будет исправить. И т.п.

[shmuz]

Но не уверен что захочу трогать части, заточенные под вашу инфраструктуру

Если новое решение будет более общим и гибким, у меня не будет проблем приспособить свою инфраструктуру под скрипт.

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

[shmuz]

В файле update.github.releases.cmd есть SET max=15 Нет ли способа указать что-то наподобие "all" ? Если нет, то может лучше установить число побольше, например 30, чтобы не править потом.

[johnd0e]

..число побольше, например 30

Каждый лишний запуск занимает заметное время, поэтому не стоит. Заранее узнать количество записей нельзя (или я не нашёл). Лучшее что приходит в голову - это после каждой итерации проверять размер файла, и прерывать цикл, как только новые записи перестают появляться.

[shmuz]

У меня 22.0 sec, (max=15) и 30.7 sec. (max=30). Не очень существенная разница.

[johnd0e]

@echo off
set file=github.releases
set GH=gh
set max=100
del %file%
echo Recreating %file% database...

setlocal enabledelayedexpansion
set lastsize=0
for /l %%x in (1, 1, %max%) do (
  echo %%x..
  %GH% api -X GET "repos/FarGroup/FarManager/releases?page=%%x&per_page=100" --jq ".[] | .name, (.assets.[].browser_download_url | select(.|test(\"7z$\") and (test(\"\\.pdb\") or test(\"ARM64\")|not)))">>%file%
  call :setsize %file%
  if !size!==!lastsize! goto :eof
  set lastsize=!size!
)
goto :eof

:setsize
set size=%~z1

[shmuz]

enabledelayedexpansion

Честно говоря, я бы предпочёл переписать этот cmd файл на Lua (можно, чтобы вся логика была на Lua, а cmd-файл остался, но был бы попроще).

Хотя возможно это мои проблемы (синтаксис MS batch-файлов меня выводит из равновесия).

[johnd0e]

Файл мне не кажется слишком сложным. Но если смотреть чуть вперёд, то действительно стоит интегрировать логику в скрипт, и обновлять кэш релизов автоматически.

[shmuz]

Файл безусловно не сложный, но в нём используются особенности языка батч-файлов, о которых я раньше вообще не знал.

[johnd0e]

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

• Можно базу в виде таблицы, для хранения сериализовать в Lua. Полмегабайта.
• Либо сразу sqlite. Но зависимость от лишней dll

Соображения?

[shmuz]

Соображения?

Предложения логичные, хотя на практике я до сих пор пользуюсь старой версией, которая качает с farmanager.com, и пользуюсь редко, т.к. больше занят far2m

Что касается лишней DLL, то вроде sqlite3.dll уже несколько месяцев поставляется в папке Far3.

[johnd0e]

Я про другую длл, ту что в комплекте с Polygon

[johnd0e]

пользуюсь старой версией, которая качает с farmanager.com

Кстати об этом, тут тоже вопрос. Если доводить данный PR до ума, то возможно стоило бы в интерфейс добавить выбор онлайн-источника. Хотя с другой стороны, сейчас там доступен лишь диапазон билдов 6325-6365, стоит ли свеч? (Через cfg выбор возможен)

Второе, это если корректно поддерживать локальные архивы, то нужно добавить регэкспов, учитывающих гитхаб-билды. Это сама по себе элементарно, но подымает очередной вопрос: билды сайта и гитхаб не совсем равнозначны, наверно не стоит их смешивать. Я бы или оставил только гитхаб, или всё-таки выбор в диалоге.

И последнее: нам ведь доступны не только "целые" билды, но иногда и промежуточные, и вероятно это тоже стоило бы взять в расчёт. Для сайта смысла мало, т.к. там фар тупо каждый день собирается, а для гитхаба смысл есть.

[shmuz]

Хотя с другой стороны, сейчас там доступен лишь диапазон билдов 6325-6365, стоит ли свеч?

Эти билды - последние на каждый данный момент, то есть позволяют вылавливать "свежие" баги. Но если реализован полноценный доступ к гитхабовским билдам, то от этих можно отказаться.

билды сайта и гитхаб не совсем равнозначны

Я вроде не сталкивался с этой неоднозначностью. Она наверное существует, но практически редко может повлиять на результат.

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