Где-то в 6 раз дешевле Firestore, и в 10 раз дешевле Dynamo

Не везде можно в CQRS, и не везде можно нагрузить такие штуки...

Универсальное решение - elastic search

У меня есть проект на ноде, который работает на GCP. Хочу добавить автоматическую проверку кода eslint-ом. Нужно ли добавлять тест когда кто-то делает PR в ветку main или нужно добавлять тест при сборке проекта в GCP(сборка идет с помощью Cloud build)? Думаю, что верный ответ: можно в обоих случаях добавить эту проверку.

Если с тестированием в облаке примерно все понятно, то что использовать на гитхабе? Я значит хочу, чтобы eslint проверял код разраба, когда тот делает PR в ветку main. Подобное тестирование раньше не писал, может кто что дельное подскажет, спасибо!

Для гитхабе Github actions. В нем пайплайны можно описать

спасибо, а travis-ci для этой же задачи служит? Никогда им ранее не пользовался.

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

ага, понял, спасибо, может кто еще что посоветует.

да, travis-ci це подібра штука, тільки трохи простіша

Eslint можно вообще в прекоммит-хук добавить

pre commit hook не гарантирует, что кто-то не закоммитит код, который не прошел проверку eslint.
git commit —no-verify и никаких хуков.
Либо же коммит до того, как установится хук

Ну тогда в гитхаб екшенс добавить...

Ну да, так и писали выше

Ну вообще если кто-то коммитит код без прогона линтерами, то можно ему палкой по спине дать

Оно и с прогонлм бывают смешные нюансы

Remote палкой

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

Ох, это да

Особенно с автоисправлением

У меня приттир было ломал sql запросы оракловские