Hudson Shellscript для экспорта исходного кода из репозитория SVN в производственную папку

У меня есть один выделенный сервер, на котором установлены весь Lamp-Stack, SVN и Hudson. Я хотел бы создать свободное задание Hudson, которое получает последний исходный код из моего SVN-репозитория и помещает его в мою папку /var/www/myWebApp.

Как должен выглядеть сценарий оболочки?

ИЗМЕНИТЬ

Когда я просто использую

svn export myRepoURL myWebAppFolder

я получаю erro, заявляя:

Started by user anonymous
Reverting http://myIpAdress/repos
Updating http://myIpAdress/repos
At revision 2
no change for http://myIpAdress/repos since the previous build
[workspace] $ /bin/sh -xe /tmp/hudson7864414135197533508.sh
+ svn export http://myIpAdress/repos/myRepo
/var/www/myWebApp
Authentication realm: <http://myIpAdress> Subversion Repository
Password for 'hudson': Authentication realm: <http://myIpAdress> Subversion Repository
Username: svn: PROPFIND request failed on '/repos/myRepo'
svn: PROPFIND of '/repos/myRepo': authorization failed (http://myIpAdress)
Finished: FAILURE

production-environment svn lamp hudson
person Pascal Klein    schedule 15.11.2010    source источник

Ответы (4)


arrow_upward
3
arrow_downward

Это должно выглядеть примерно так, как показано ниже

svn export [ваш URL-адрес svn] /var/www/myWebApp

Дайте мне знать, если я что-то здесь упустил?

person Version Control Buddy    schedule 15.11.2010
comment
Большое спасибо, голоса показывают, что это правильное решение. Но когда я использую ваш код, я получаю сообщение об ошибке. пожалуйста, ответьте на мое редактирование. - person Pascal Klein; 15.11.2010
comment
Ошибка в основном потому, что при запуске команды экспорта svn ищет имя пользователя и пароль. Subversion имеет возможность сохранить пароль локально при первой операции. Таким образом, чтобы избежать этого, вы можете выполнить фиктивную проверку (или аналогичную операцию), которая заставит subversion хранить учетные данные локально. - person Version Control Buddy; 16.11.2010
comment
@paskster: кстати, вам нужно сделать это от имени того же пользователя, которого вы запустили hudson. - person Version Control Buddy; 16.11.2010

arrow_upward
1
arrow_downward

Я бы тоже просто запустил копию. Не копируйте папки .svn и другие файлы, которые не должны быть доступны извне.

Я также посмотрел команду svn export, и она выглядит даже лучше. Если ваша работа настроена на оформление заказа из svn, вы также можете запустить svn export ${WORKSPACE}/* /var/www/myWebApp. При этом будут скопированы только те файлы, которые находятся под контролем источника. Однако это даст вам возможность изменить некоторые конфигурации (которые также важны для среды, которую вы развертываете) перед развертыванием на вашей цели.

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

person Peter Schuetze    schedule 15.11.2010

arrow_upward
0
arrow_downward

Напишите сценарий для копирования (используя команду «cp») всех файлов из рабочей области задания в любое место, которое вы хотите. Вы должны использовать переменную среды 'WORKSPACE', предоставленную Hudson, которая предоставляет вам путь к рабочему пространству задания. Скрипт, скорее всего, сможет работать в любой используемой вами оболочке.

person Bernard    schedule 15.11.2010

arrow_upward
0
arrow_downward

Я думаю, что ранее упомянутое svn export является правильным решением, но если вы собираетесь делать копию, я рекомендую что-то вроде rsync или tar вместо голого cp. Оба позволят вам исключить определенные файлы или каталоги, обратитесь к параметру командной строки --exclude. (Поиск tar exclude svn в Google укажет вам правильное направление.) Преимущество Rsync заключается в том, что он копирует только изменений, поэтому развертывание выполняется намного быстрее, если изменилось лишь небольшое количество файлов.

Другие вещи, которые следует учитывать:

  • У вас должен быть план удаления файлов, которые больше не являются частью репозитория.
  • Вам следует подумать о том, как вы будете управлять конфигурацией своего веб-приложения. Я не рекомендую проверять конфигурацию развертывания в subversion, особенно если другим разработчикам необходимо внести изменения в эту конфигурацию для локального тестирования. Случайное изменение конфигурации в subversion слишком легко может сломать вашу производственную систему.
person Dave Bacher    schedule 15.11.2010