У меня есть проект, который использует Serve и контролируется версиями с помощью Git. Служба создает outputпапку со статическими файлами, которые я хочу развернуть в Heroku.

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

Есть ли способ развернуть подпапку на git remote? Должен ли я создать репозиторий Git в outputпапке (звучит неправильно) и отправить его в Heroku?

Есть еще более простой способ - через git-subtree . Предполагая, что вы хотите отправить свою папку output как корень Heroku, вы можете сделать:

git subtree push --prefix output heroku master

В настоящее время кажется, что git-subtree включается в git-core, но я не знаю, была ли выпущена эта версия git-core.

Я начал с того, что сказал Джон Берриман, но на самом деле это может быть проще, если вас совсем не заботит история heroku git.

cd bin
git init
git add .
git commit -m"deploy"
git push git@heroku.com:your-project-name.git -f
rm -fr .git

Думаю, официальный git subtree- лучший ответ, но у меня возникла проблема с тем, чтобы поддерево работало на моем Mac.

У меня была аналогичная проблема. В моем случае никогда не было проблемой удалить все в репозитории heroku и заменить его тем, что находится в моем подкаталоге. Если это ваш случай, вы можете использовать следующий сценарий bash. Просто поместите его в каталог вашего приложения Rails.

#!/bin/bash

#change to whichever directory this lives in
cd "$( dirname "$0" )"

#create new git repository and add everything
git init
git add .
git commit -m"init"
git remote add heroku git@heroku.com:young-rain-5086.git

#pull heroku but then checkback out our current local master and mark everything as merged
git pull heroku master
git checkout --ours .
git add -u
git commit -m"merged"

#push back to heroku, open web browser, and remove git repository
git push heroku master
heroku open
rm -fr .git

#go back to wherever we started.
cd -

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

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

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

это могло быть и rsync, они пошли на git, не отвлекайтесь из-за этого

если вы сделаете это, вы откроете себя для всех видов боли. Все вышеупомянутые решения где-то с треском проваливаются:

1. он требует, чтобы что-то делалось каждый раз или периодически, или происходили неожиданные вещи (подталкивание подмодулей, синхронизация поддеревьев, ...)
2. если вы используете движок, например, для модулирования своего кода, Bundler съест вас заживо, невозможно описать количество разочарования, которое я испытал по поводу этого проекта во время поисков хорошего решения для этого
   • вы пытаетесь добавить движок как git repo link + bundle deploy- сбой, вам нужно каждый раз связывать обновление
   • вы пытаетесь добавить движок как :path+ bundle deploy- неудачно, команда разработчиков рассматривает :pathвариант как «вы не используете Bundler с этим параметром драгоценного камня», поэтому он не будет комплектоваться для производства
   • кроме того, каждое обновление движка хочет обновить ваш стек рельсов -_-
3. единственное решение, которое я нашел, - использовать движок в качестве /vendorсимволической ссылки при разработке и фактически копировать файлы для производства

Решение

Рассматриваемое приложение имеет 4 проекта в git root:

1. api - в зависимости от профиля будет работать на 2 разных хостах heroku - upload и api
2. web - сайт
3. web-old - старый веб-сайт, все еще в процессе миграции
4. common - общие компоненты, извлеченные в двигателе

У всех проектов есть vendor/commonсимволическая ссылка, указывающая на корень commonдвижка. При компиляции исходного кода для развертывания в heroku нам нужно удалить символическую ссылку и rsync, чтобы его код физически находился в папке vendor каждого отдельного хоста.

1. принимает список имен хостов в качестве аргументов
2. запускает git push в вашем репозитории разработки, а затем запускает чистый git pull в отдельной папке, гарантируя, что никакие грязные (незавершенные) изменения не будут автоматически отправлены на хосты
3. развертывает хосты параллельно - каждый репозиторий heroku git вытягивается, новый код синхронизируется в нужные места, фиксируется с базовой информацией о push в комментарии git commit,
4. в конце мы отправляем ping с curl, чтобы сообщить ведущим, чтобы они проснулись и проследили журналы, чтобы увидеть, все ли прошло
5. хорошо играет и с Дженкинсом: D (автоматическая отправка кода на тестовые серверы после успешных тестов)

Работает очень-очень красиво в условиях дикой природы с минимальными (нет?) Проблемами уже 6 месяцев

Вот сценарий https://gist.github.com/bbozo/fafa2bbbf8c7b12d923f

Обновление 1

@AdamBuczynski, никогда не бывает так просто.

1-й, у вас всегда будет как минимум производственная и тестовая среда - и, в худшем случае, куча специфичных для функций кластеров - внезапно 1 папка должна быть сопоставлена ​​с n проектами heroku в качестве довольно простого требования, и все это нужно как-то организовать так, чтобы сценарий «знает», какой источник вы хотите развернуть,

sync_commonВо-вторых, вы захотите поделиться кодом между проектами - теперь наступает часть, махинации с символическими ссылками в разработке заменяются реальным rsynced кодом на Heroku, потому что Heroku требует определенной структуры папок и бандлера, а rubygems действительно действительно очень сильно делают вещи уродливыми, если вы хочу извлечь общие нити в драгоценный камень

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

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

Мне действительно стоит подумать о том, чтобы объединить вещи в Rakefile или что-то в этом роде и сделать все таким образом ...