А если серьезно - выпущен альфа-релиз BSL Language Server под номером 0.20.0-ra.1.
Что такое альфа/пре-релизы?
В разработке любого программного продукта _иногда_ возникают точки, когда можно сказать: "Вот сейчас вроде не сильно разваливается, можно попробовать погонять". BSL LS и зависящий от него плагин для SonarQube не исключение. Наиболее стабилен продукт, конечно же, перед релизом (еще не найденные баги в расчет не берем), поэтому можно выпускать так называемые релиз-кандидаты, чтобы оценить будущий релиз на общую работоспособность и найти ново-привнесенные ошибки с некоторой надеждой на их исправление.
Но и обычные сборки внутри цикла разработки тоже могут быть интересны. Это всяческие альфа-бета-майлстоун да и просто снапшот-версии, которые разработчики могут опубликовать в виде pre-release на GitHub или просто скинуть сборку в чат
@bsl_language_server.
Почему их важно тестировать?
Во-первых, там может быть исправлена та самая раздражающая именно вас ошибка. Уже повод, не правда ли?
Во-вторых, там могут быть добавлены новые крутые фичи! Ну или не новые. Или не крутые. Но что-то уж точно будет добавлено!
В-третьих, (вы не поверите) вы можете обнаружить ошибки! Особенно это касается новой функциональности, будь то новая диагностика или добавление показа квадратика с цветом, который падал в окне git diff в VSCode (и за две недели тестирования пре-релизов никто об этом не сообщил,
ярость, вопли, драмматизм).
Как их тестировать?
Если вы счастливый пользователь VSCode и хотите тестировать BSL LS в более-менее "зеленом" состоянии, откройте "Настройки", найдите настройки расширения
Language 1C (BSL), и переткните настройку
Language Server Release Channel со значения
stable на значение
prerelease. Да, там не всегда именно релиз-кандидаты, но в любом случае это код, который прошел ревью, имеет зеленые тесты и уж точно полной неработоспособной херней не окажется. Кого я обманываю, каждый пре-релиз может оказаться херней, но вы же ради выяснения этого и хотите тестировать, да?
Если вы хотите большего хардкора, можете переткнуть в истину флажок
Language Server External Jar и указать путь к полученному (откуда-то) exec.jar-файлу в настройке
Language Server External Jar Path. Иногда в телеграм-чате кидается клич с "просьбой потестить" и готовым файликом. Напомню, что вы всегда можете собрать BSL Language Server из любой ветки, имея на машине java11+, выполнив
./gradlew bootJar и забрав файл с окончанием
-exec.jar (жирненький, на 80 метров который) из папки
build/libs. Этот же файл можно подкладывать в Phoenix BSL, конннектор к EDT, Снегопат и прочие инструменты, которые интегрируются с BSL Language Server.
И для самых отъявленных садомазахистов есть вариант сборки сонар-плагина с дев-сборкой BSL LS. Для пре-релизов достаточно поменять версию зависимости в файле
build.gradle.kts и выполнить
./gradlew jar. Если вы хотите потестировать не-пререлиз, то вы и так знаете, что делать :) Впрочем, сборки сонар-плагина на релиз-кандидатах обычно оперативно появляются либо в пре-релизах самого сонар-плагина, либо все в том же чате BSL Language Server.
Короче, если вы за прогресс, хотите помочь и готовы хотя бы иногда репортить возникающие ошибки - хотя бы переткните релизный канал в VSCode. Это уже поможет отловить кучу ошибок.
И вот даже автосгенерированный чейнджлог по новой альфа-версии BSL Language Server под рукой:
https://github.com/1c-syntax/bsl-language-server/releases/tag/v0.20.0-ra.1
