так что бери инфу 2011+ годов и будь спокоен за актуальность

meh

все зависит от того, что ты не пропустил

мне уже года 3 говорят что мертво, но все как то не умрет

ну еще долго не умрет

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

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

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

Свой код почитать)

Свой код почитать)

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

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

Не самый плохой вариант)

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

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

да, звучит разумно

внимание, загадка в deploy.rb стоит set :branch, 'master' в коде, взятом из папки current, активная ветка - deploy как это объясняется?

кто-то на локали поменял, задеплоил и в репозиторий не закомитил)

а вообще у capistrano есть файлик revisions.log кажись

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

кто-то на локали поменял, задеплоил и в репозиторий не закомитил)

Так код-то все равно из репы берется, а не с локального компа

кто-то на локали поменял, задеплоил и в репозиторий не закомитил)

а как он мог задеплоить без коммита в репу?

А как это связано? ?

При деплое через капистрану с гитом махинаций кагбэ нет

это вообще не связано, потому как капистрано использует локальный скрипт

ну точнее не так, он использует конфиги те, где он запускается

При деплое через капистрану с гитом махинаций кагбэ нет

а можно по русски?

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

посмотри revisions.log, там будет что-то вроде: Branch default (at 24183b8bcb8d5b85c61c51338a4a05198e510f83) deployed as release 20160605170301 by dstepanenko Branch default (at 38af944ca56f79d2a108ef1b7ae81272cbe4dcf7) deployed as release 20160605181446 by dstepanenko

и ты сразу определишь что произошло

И неважно какое состояние репозитория локально

+

в смысле - неважно?

мне вот важно

В смысле, что капистарне не важно

Она просто зальет текущий код из указанной репы и указанной ветки на сервек

капистрано скачивает исходник из github (или bitbucket) и заливает его на сервер. И ему пофигу что у тебя локально

капистрано скачивает исходник из github (или bitbucket) и заливает его на сервер. И ему пофигу что у тебя локально

Именно

это не у меня локально

это на сервере локально

ты revisions.log посмотрел на сервере?

нет, я не знаю, где его искать

у тебя капистрано заливает все в какую-то папку, например: /var/www/site.com

там есть три папки (current, revisions и shared)

вот в корне будет лежать этот файл

/var/www/site.com/revisions.log

ни разу такого не видел

set :deploy_to

вот сюда оно заливает

в эту директорию

там нет

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

это вроде с 3 появилось

версии два

хмм, во второй не помню, был ли такой лог...

не было

в второй файлы REVISION

ну в общем я не вижу другого варианта кроме как что кто-то локально изменил конфиг capistrano, сделал cap production deploy и на сервере получилась ветка отличная от конфига. К сожалению как посмотреть логи деплоя в capistrano 2 я не знаю

а не мог этот кто-то сделать git checkout <ветка> и git pull?

или даже без git pull

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

если имела место именно такая схема, можно просто по истории команд на сервере поискать. Что-то вроде history | grep git

Какие-то влажные фантазии капистрано вызывает

Вы бы хоть в сырцы глянули.

При деплое во второй версии происходит следующее 1. Капистрано сливает bare репозиторий на сервере деплоя вашу ветку указанную в конфиге (это всё кэшируется в папку repo). 2. Капистрано создаёт папку под текущий релиз. 3. Инициализирует в ней git. 4. Клонирует туда репозиторий из кэша. 5. Создаёт ветку deploy в папке релиза.

Инжой https://github.com/capistrano/capistrano/blob/v2.15.9/lib/capistrano/recipes/deploy/scm/git.rb#L149

о!

Это захардкожено и не очень красиво.

В 3-ей версии все сделано более элегантно. Но её сырцы вы посмотрите сами, правда же.

нит

ERROR: S client not available

зачем

Ясно, понятно.

Это захардкожено и не очень красиво.

Спасибо, не знал про такое. Я просто работал с hg все время и 2 и 3 версии не делали там такой фигни. Как интересно

видимо для git другая схема зачем-то сделана

Переезжайте на 3-ий капистрано.

у меня и так третий) просто вместо git у меня меркуриал)

Аааа... Понял. В третьем логика изменена, если меня память не подводит.

Там в принципе все scm-утилиты вынесены в плагины для начала.

а в чем прикол меркуриал?

или это просто на проекте так?

ну мы исторически переехали на него с svn и меня устраивает)

Кто-то любит арбуз, а кто-то свиной хрящик

А кто какой http либой пользуется? RestClient крутой, но если тебе вдруг надо увеличить тайм-аут, то приходится уже менять приятный метод #post или #get на #execute, в котором уже не все так красиво.

А кто какой http либой пользуется? RestClient крутой, но если тебе вдруг надо увеличить тайм-аут, то приходится уже менять приятный метод #post или #get на #execute, в котором уже не все так красиво.

Напиши свою обёртку

Или забей

мне нравится https://github.com/sparklemotion/mechanize

ну тут не то все же

это через веб обращения, а rest client считай обычный curl

зато сразу два в одном) зачем подключать разные либы если одна комбаин

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

А кто какой http либой пользуется? RestClient крутой, но если тебе вдруг надо увеличить тайм-аут, то приходится уже менять приятный метод #post или #get на #execute, в котором уже не все так красиво.

https://github.com/jnunemaker/httparty есть такое, но не уверен, что норм. но некоторые используют

вот этот еще популярный вроде https://github.com/lostisland/faraday

вот этот еще популярный вроде https://github.com/lostisland/faraday

точняк

ох ё, это ж обёртка

)

ну ладно. но выглядит так себе, на мой вкус

httparty не обновляется

Спасибо, буду смотреть. Вообще когда пришлось кучу запросов разных делать в одном месте, то оказалось, что только Curb может с нормальной скоростью передавать большие файлы, да и RestClient оказался не очень гибким и при первом же изменении пришлось использовать более низкоуровневый метод, о котором даже разработчики restclient пишут, что там уже все не так гладко. Конечно от Curb для передачи больших файлов вряд ли удастся избавиться, но это все-таки редкая задача, а вот найти что-то более гибкое, чем RestClient, но достаточно удобное было бы круто :)

https://github.com/markets/awesome-ruby#http-clients тут еще куча их)

https://github.com/typhoeus/typhoeus

самый норм на мой взгляд

на основе libcurl