но при этом компилируются оба проекта (основной и тест) сразу или тест будет компилироваться только при самом sbt test?

Я больше по devops, поэтому для меня sbt и как он работает с проектами пока "тёмный лес"), что означает должен быть в SNAPSHOT версии? Как этого добиться на этапе компиляции?

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

В команде выше 2 действия sbt:
1. опубликовать проект с названием mainProject в локальный реп (по умолчанию в папке ~/.ivy2)
2. запустить команду test в проекте testProject

Что значит SNAPSHOT версия - что номер версии заканчивается на SNAPSHOT, например 0.1.0-SNAPSHOT и установлена настройка isSnapshot ( https://www.scala-sbt.org/1.x/docs/Publishing.html )

testProject от mainProject должен зависить не через .dependsOn(mainProject), а через libraryDependencies

спасибо! сейчас с разработчиками проговорим как это лучше сделать и проверить по итогу

разработчики, скорее всего, не оценят

Идея очень плохо работает с таким

и других вариантов нет? иметь отдельный build.sbt  для разработки и отдельный для CI/CD тоже не получится?

Получится, но поддерживать тяжело

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

Он "подкладывается" копированием или монтированием? Если копированием, то там атрибуты файлов (например даты) не меняются? Инкрементальная компиляция, насколько помню, не на основе хеша файла, а на основе даты последнего изменения.

Скаланы, есть вопрос по реализации graceful shutdown на cats-effect 2 и fs2.

Допустим, у меня есть некий сервис, который торчит стримовым апи наружу:

class MyService[F[_]] {
  def run: fs2.Stream[F, String] = ???
}
object MyService {
  def apply[F[_]]: Resource[F, MyService[F]] = ???
}

Пример использования:

MyService[IO].use { myService =>
  myService.evalMap { x =>
    IO(println(x))
  }
}

Я хочу сделать для него возможность graceful shutdown. Это значит, что когда пришел cancelation, то не сразу убивать всё, а дождаться завершения работы стрима и только потом всё закрыть.

В скасти я накидал запускаемый пример: https://scastie.scala-lang.org/LMnet/WLu8SCkGQlOdqaJXhZE8sA/3 Там тупейшая реализация которая берёт из массива строк элементы по одному и паблишит. Я хочу, чтобы даже в случае канцелейшона я дочитывал всё до конца, и только потом умирал.

В коде из скасти есть 2 проблемы:
1. Нужно явно вызывать uncancelable на стриме. Я бы хотел, чтобы это было скрыто. То есть, чтобы это было часть поведения самого сервиса.
2. Приложение никогда не завершается. fiber.join просто висит. Я так понимаю, причина в uncancelable. Но если его убрать, то стрим не будет завершаться как мне надо.

Каким образом мне достичь желаемого поведения? Возможно, я вообще не в ту сторону копаю, и проще сделать принициально другой дизайн моего сервиса, чтобы это заработало?

первоначально было через монтирование, откуда проблема и полезла. Т.е. git-репа была общая для первого этапа (compile) и для второго этапа (test+assembly). Я так и не понял до конца что именно "увидел" sbt тест в структуре репы (она была локально склонирована и содержимое в ней не менялось, за исключением созданных target/....), но в режиме sbt --debug --verbose было указано  [debug] Recompiling all sources: number of invalidated sources > 50.0% of all sources и начинался процесс повторной сборки

в последних сбт что-то делали с датами файлов вроде, чтоб получать каждый раз одинаковые бинари на выходе

а, это только для jar

Привет никто не подскажет как получить UTF-8 такого плана из строки. val str = "Пример";  foo(str) // "Пример"

Ну если найдёте хорошее решение - пишите.
У нас это было одной из мотиваций двигаться в базель

пока нашёл не очень хорошее - попробую тащить всю репу вместе с собранными бинарниками по всем стадиям как копию, а не через точку монтирования. А на последней стадии (после test) буду собирать только нужные мне jar в отдельный каталог

partially applied function?

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