Что есть конфиг. И почему то ребята в последних версиях сделали это ошибкой

собсно в этом и был вопрос.

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

Я за babel и ноуд взялся недавно, запилил такой проект и решил его на сервер себе задеплоить. https://github.com/Archakov06/trycode

О нём и шла речь

Что есть конфиг. И почему то ребята в последних версиях сделали это ошибкой

как правило называется

1 сек

https://www.dropbox.com/s/ulinr8qf9getr28/Скриншот%202017-01-20%2014.31.18.png?dl=0 https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-extraneous-dependencies.md

вопрос. Если я внёс изменения, которые должны использоваться только для хероку, но не должны вноситься и в гитхаб, при использовании команды git push herokue master, в следующем пуше, эти изменения не внесутся в гитхаб?

внесутся

прочитай https://git-scm.com/book/en/v2

вопрос. Если я внёс изменения, которые должны использоваться только для хероку, но не должны вноситься и в гитхаб, при использовании команды git push herokue master, в следующем пуше, эти изменения не внесутся в гитхаб?

Кстати за хероку и гитхаб

Хероку умеет деплоить прямо из гитхаба по нажатию или автоматом при коммитах

Что-то у меня атом начал 100% проца жрать.

Точнее, электрон. И дело в глобалменю.

Хероку умеет деплоить прямо из гитхаба по нажатию или автоматом при коммитах

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

Да

Стоп

Нет

Будет деплоить

В хероку

да, я понял. Спасибо за инфу, посмотрю

Зарепортил им баг вида «всё сломалось, ничего не работает»: https://github.com/electron/electron/issues/8455

прочитай https://git-scm.com/book/en/v2

Я убил 30 минут в поисках ответа в документации, ничего нужного не нашел, но прочёл полезное, однако не по моему вопросу.

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

приватный репо или вынести все секреты в config vars и передавать их через heroku config:set MY_SECRET_STRING=xxx

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

ты не должен хранить конфиги с приватными токенами в репозитории

Я убил 30 минут в поисках ответа в документации, ничего нужного не нашел, но прочёл полезное, однако не по моему вопросу.

глава про ремоуты нужна

приватный репо или вынести все секреты в config vars и передавать их через heroku config:set MY_SECRET_STRING=xxx

вот дело советуют

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

env variables

вон же heroku config

Я понял, но мне ведь не в хероку надо, а в деплой на основной сервер.

тогда на сервере

git push heroku - heroku.com git push github - github.com git push deploy - server.com

странно, не думал что так замарачиваться надо будет

strict separation of config from code

эм

у тебя деплой странный

странно, не думал что так замарачиваться надо будет

Конфиги не должны входить в репозиторий

https://12factor.net/config

и деплой наврядли должен происходить по гит пушу

деплой должен быть по вебхуку от репозитория

Ну с точки зрения пользования это одно и то же

ну хз

по пушу абсолютно ручной труд

по хуку автоматически

хотя у меня самого после пуша надо идти на сервак и пуллить ветку и forever restartall делать

Ибо не дошли руки нормально сделать

Что и требовалось доказать

хотя у меня самого после пуша надо идти на сервак и пуллить ветку и forever restartall делать

зачем тебе форевер?

На сервере.

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

Но форевер этого не гарантирует же.

гарантирует в какой то степени

В довольно хреновой. Ничего не мешает самому фореверу подохнуть когда система решит прибить что-нибудь по оом.

он гарантирует, что пока он работает, он будет перезапускать

в какой то другой степени ничто тебе ничего не гарантирует

он гарантирует, что пока он работает, он будет перезапускать

он может сдохнуть запросто

хз насчет forever, а pm2 умеет система переподнимать

все может сдохнуть

через service

в какой то другой степени ничто тебе ничего не гарантирует

любой системный менеджер гарантирует это пока это вообще возможно

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

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

Да, но: 1) тогда зачем в цепочке форевер? 2) спорим, что @Oharr этого не делает?

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

И нет, всё не так просто.

ERROR: S client not available

Кроме защиты от падений надо реализовывать ещё проверку состояния, и форевер это ломает.

кто шарит в кронтасках?

(то есть, условно, наше приложение-сервер пингует менеджер нотификациями раз в секунду, если нотификация не пришла — менеджер принудительно ребутит приложение)

Или наоборот — менеджер раз в секунду спрашивает сервер о его состоянии — так тоже можно.

(но это лишняя работа)

И кто так вообще делает?

Все так делают, разве нет?

первый раз слышу

http://0pointer.de/blog/projects/watchdog.html

Почитай.

Я верю что такая фича есть в systemd

Нет, я о том, что она активно используется.

Я не верю, что ее все повально используют

И - ничто не мешает сделать то же самое forever

Как именно?

pm2 так делает

Точно так же?

само пингует что надо

pm2 так делает

Я не нашёл RuntimeWatchdogSec в коде pm2, кстати, это значит, что в его интеграции с системд системд не проверяет, что пм2 живой вообще.

У pm2 кстати было очень много воплей на то, что он падает и всё дохнет, люди с удивлением узнавали, что pm2 в вакууме на боевом сервере — очень плохая идея.

Да почему плохая то?

Но сейчас там, говорят, сделали интеграцию с systemd, надо смотреть, как именно.

Идея как идея

Нужно понимать, какие сценарии покрывает, какие нет

Да почему плохая то?

Потому что на боевом сервере всё к чертям дохло и само не поднималось.

И сервер сам может сдохнуть

Вопрос, зачем вам вообще pm2 на продакшене?

Хотя пользователи этого почему-то ожидали.

И датацентр сгореть

И земля может быть уничтожена метеоритом

От всего этого pm2 не спасет

И датацентр сгореть

Это другой вероятности проблемы.