потом ты пишешь код пайплайна который является самой джобой уже

чувствуете какое веселое развлечение)

самая большая боль у меня от пайплайн плагина в том что он умеет только булеан и стринг параметры

а если мне надо гит ветку?

ты создаешь руками джобу в дженкинсе которая запускает код который генерит тебе джобы

так часто приходится создавать новые?

ну аргумент - типа это разовая операция конечно можно привести в оправдание но я с ним не соглашусь)

вобщем я считаю что пайплайны должны были быть сделаны как в gocd, вот там по человечески сделано

в женкинсе это просто мешанина, надо сидеть и курить весь этот бардак, потому что из документации нифига не ясно

Если было бы иначе, то это был бы не опенсорс))

Ну чего ты как маленький) Берешь пайплайн в руку и начинаешь создавать джобу...

Открываешь голубой океан, указываешь репу. Готово

Ну наконец https://github.com/scalapb/ScalaPB/commit/92bb35f5cd4ab3c8ca4a4792f97f99c5ef793caf

Открываешь голубой океан, указываешь репу. Готово

Голубой океан уменьшает боль, да. Он ведь умеет читать только один Jenkinsfile в корне проекта, так? А если у меня мультимодульный проект и я хочу несколько пайплайнов как мне быть? Насколько я знаю я не могу больше одного пайплайна описать в Jenkinsfile а значит и больше одной джобы сгенерить, на один репозиторий так? Плюс непонятно что делать если тебе надо задать параметр джобы - гит бранч.

вобщем чуваки осилить не могут 8 месяцев фичу и хз когда осилят https://issues.jenkins-ci.org/browse/JENKINS-43749

Голубой океан уменьшает боль, да. Он ведь умеет читать только один Jenkinsfile в корне проекта, так? А если у меня мультимодульный проект и я хочу несколько пайплайнов как мне быть? Насколько я знаю я не могу больше одного пайплайна описать в Jenkinsfile а значит и больше одной джобы сгенерить, на один репозиторий так? Плюс непонятно что делать если тебе надо задать параметр джобы - гит бранч.

Нет, есть вроде как мулитьбранч паиплайн

это другое насколько я понимаю

Ну это на каждый Бранч свои файл можно сделать

Ты можешь сделать pr))

вобщем это не то) натягивание плагина на задачу)

отсюда вытекает непонятный момент: вот есть у меня всеми любимый сбт например в проекте, я могу выполнить таски: - deploy - yaSboduna вторую таску я хочу выполнять только 1-го января. Мне ведь для этого надо создать новый пайплайн? И куда мне запихать Jenkinsfile c этой таской?

вобщем не хватает гибкости. А ещё было бы круто в dsl сделать что-то типа pipeline { dependsOn: anotherPipeline }

тогда надо иметь именованные пайплайны, а они не имеют имени насколько я понимаю

вобщем засада за засадой

отсюда вытекает непонятный момент: вот есть у меня всеми любимый сбт например в проекте, я могу выполнить таски: - deploy - yaSboduna вторую таску я хочу выполнять только 1-го января. Мне ведь для этого надо создать новый пайплайн? И куда мне запихать Jenkinsfile c этой таской?

Не, все в одном описывай

делать магию с when или как?

Ну груви ж

вобщем пичаль, борьба с ограничениями

минутка скрытой рекламы на канале, вот как надо было делать https://www.youtube.com/watch?v=1AfBxCWRqD8

Не знаю, у меня простой пайплайн)

самая большая боль у меня от пайплайн плагина в том что он умеет только булеан и стринг параметры

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

Через $class, не могу сейчас пример найти, но точно работало

Нужна помощь. Только скачал плагин scala на intellij idea, классы создавать не дает, только script и worksheet. Проблему погуглил, так и не понял как решить

У кого такое было? Может кто подсказать, что делать с этим? Нужно вроде как установить SDK, что-то в этом духе

Проект как скала создавался?

Да, с sbt

Там на панельке Билд тулов справа можно попробовать щёлкнуть рефреш

Он должен подтянуть все нелостающее

Не нашел кнопки такой

У меня стоит java jdk как project sdk

Как сделать scala sdk?

в project settings добавитть нужный scala sdk

ну и прописать версию скала в sbt

Откуда мне взять scala sdk

Я плагин качал через idea

В офф инструкции на сайте scala пишут, что sdk автоматом скачается при запуске нового проекта

У меня периодически такое бывает. invalidate cache and restart помогает

Кнопку там без скрина и правда тяжело найти

Может я не так что-то делаю, т.к. совсем не разбираюсь

В офф инструкции написано, что на этом этапе должна возникнуть кнопка create и потом download для scala sdk

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

Invalidate cache and restart не дало ничего

Я конечно нарываюсь на гнев Алексея, а если попробовать в темринале sbt compile в корне проекта?

Я конечно нарываюсь на гнев Алексея, а если попробовать в темринале sbt compile в корне проекта?

иногда срабатывает подверждуаю

иногда срабатывает подверждуаю

С праздничком коллега ?

На всякий случай отпишу, если у кого возникнет похожая проблема

Это решение помогло

Привет! А есть ли живой опенсорсный проект на akka-http, чтобы посмотреть как правильно тесты писать и логику на большом проекте?

https://github.com/ArchDev/akka-http-rest

да как обычно, у тебя будет слой web/controller/resource (кто как называет) со всеми akka-http радостями, который будет дёргать service layer, который уже не будет знать про akka-http

примеры тестов есть в доке

https://github.com/ArchDev/akka-http-rest

Я пробовал тесты как там и возникли сомнения, что это правильно: отдельные тесты для роутинга с замоканым сервисом, для стораджа и для сервиса. Или так и нужно делать? Просто я подумал, что проще и эффекивнее сразу реальный сервис дергать с роутинге и проверять на сквозь весь функционал.

Я пробовал тесты как там и возникли сомнения, что это правильно: отдельные тесты для роутинга с замоканым сервисом, для стораджа и для сервиса. Или так и нужно делать? Просто я подумал, что проще и эффекивнее сразу реальный сервис дергать с роутинге и проверять на сквозь весь функционал.

правильнее это или нет хз, это же вообще разные подходы

ERROR: S client not available

одно дело тестить небольшие куски функционала, а другое дело целый роут

без моков и т.д.

Да, хз...

почему бы не тестить сервис на уровне сервиса? Зачем это делать через веб слой?

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

Я подумал, что так меньше тестов выйдет в итоге.

если надо меньше тестов - тестишь сразу живой рест, от таких тестов реально больше толку (интеграционных)

Зачем писать тесты ради тестов (или это оправдано)? Если я не понимаю как именно мне нужно написать тест, я его обычно не пишу.

Вообще последние пару проектов вышли в коммерс благодаря тому что выпилили кучу жутких тестов ради тестов из них. Так бы и лежали красными оттягивали сроки.

Отличный подход, я считаю

Зачем писать тесты ради тестов (или это оправдано)? Если я не понимаю как именно мне нужно написать тест, я его обычно не пишу.

Кстати часто это может быть сигналом к тому, что нужно уменьшать связанность.

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

А есть какая-то причина не использовать embedded postgres в тестах? Или как вообще правильно поднимать субд для тестов?

А есть какая-то причина не использовать embedded postgres в тестах? Или как вообще правильно поднимать субд для тестов?

тестконтейнерс же

тестконтейнерс же

плюсую

чтот Серега плохо старается, раз мало кто о них знает

это https://www.testcontainers.org/?

да

А есть какая-то причина не использовать embedded postgres в тестах? Или как вообще правильно поднимать субд для тестов?

контейнер дажи докер любой простой с сидами

Я пробовал тесты как там и возникли сомнения, что это правильно: отдельные тесты для роутинга с замоканым сервисом, для стораджа и для сервиса. Или так и нужно делать? Просто я подумал, что проще и эффекивнее сразу реальный сервис дергать с роутинге и проверять на сквозь весь функционал.

я в своих проектах роуты не тестирую в принципе, у меня обычно на это времени нет

с тестконтейнерами найс идея

чтот Серега плохо старается, раз мало кто о них знает

кому надо - знает) отличная штука

куда более универсально

только главное не на каждый тест поднимать инстанс докера)) а то весело будет

Спасибо ребята!

я в своих проектах роуты не тестирую в принципе, у меня обычно на это времени нет

аналогично

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

Денис, ты вернулся на Scala?

Ну я как бы особо не уходил, просто в spark-е скала скучная =)

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

Это не повод их не писать)