Чи можу я використовувати свій існуючий git repo за допомогою функції openhift?


102

Чи потрібно мати git repo лише у режимі openhift? У мене вже є bitbucket / github git repo, і я вважаю за краще лише туди. Чи можу я просто зачепитися за нього, щоб відкритий зсув набув залякування?

Або для спрощення, я натискаю лише на github, але коли я хочу розгорнути, я щось роблю з відкритим зсувом?

Я перевірив це, але це мене збентежило: це мова про злиття вихідного та нового (openhift) git?


6
Не могли б ви перечитати запитання? Це дуже важко зрозуміти.
Метт Фенвік

Відповіді:


226

У мене таке враження, що ти ще не звик вживати git. Я б радив вам увійти в git, щоб повністю зрозуміти, як підштовхнути свій код до відкритої зміни. Тим не менш, дозвольте мені спробувати пояснити ваші кроки: Як ви робите з git в цілому, тут вибираєте підхід до клонування іншого git repo (наприклад, на bitbucket) на вашу локальну машину:

git clone <bitbucket-repo-url>

Тоді ваш локальний клон має ваше інше репо (бітбукет тощо) як віддалений репо. Віддалене репо зберігається з псевдонімом "origin" (псевдонім за замовчуванням, який використовується git, якщо ви клонуєте). Потім ви додаєте репо, що відкривається, як віддалений до свого клону. Ви робите це, однозначно використовуючи псевдонім для віддаленого репо, який ви додаєте - я тут використовую "openshift" як псевдонім:

git remote add openshift -f <openshift-git-repo-url>

Для того, щоб потім можна було виштовхнути код з локального git repo до openhift, спочатку вам потрібно з’єднати вашу репосту openhift з локальним клоном bitbucket. Ви робите це, видаючи локально:

git merge openshift/master -s recursive -X ours

За допомогою цієї команди ви повідомляєте git об'єднати головну гілку в openhift git repo з вашим локальним git repo. Ви говорите йому для злиття за допомогою рекурсивної стратегії злиття та вибору вашої ("нашої") версії, коли виникають конфлікти.

Як тільки злиття виконане, ви готові підштовхнути git repo до відкритого перемикання. Ви робите це, роблячи:

git push openshift HEAD

Ви говорите git підштовхнути свій локальний код до гілки HEAD на віддаленому репо, який називається "openshift" (псевдонім, на якому ми зберігали git repo openshift, деякі пункти далі).

btw. Я написав блог інструментів jboss, який демонстрував, як використовувати Openhift-java-клієнт кілька місяців тому: https://community.jboss.org/wiki/Enable-openshift-ciFullExampleUsingOpenshift-java-client . Ви побачите вищезазначені кроки в останньому абзаці "Ми майже там".


30
Я думаю, це все ще не відповідає на питання. Питання полягає в тому, щоб не використовувати git repo openshift як віддалений, а замість цього використовувати репо на github (або бітбукет для цього питання) як git repo. Натискання на github repo, що використовується для співпраці, також повинно забезпечити відображення в режимі openhift. Я теж шукаю те саме, але не знайшов відповіді. Я спробую оновити, якщо знайду для цього рішення
Manoj NV

9
Ви не можете використовувати git repo openhift. Git repo в OpenShift - це те, як ви передаєте OpenShift свій код. Немає альтернативи, немає "використовувати замість github". Як я намагався окреслити вище, git repo на OpenShift не виключає вас від використання github. Якщо ви використовуєте github / bitbucket / XX в якості основного репортажу управління джерелом - і більшість користувачів це зробить -, ви просто додасте gitub repo OpenShift як віддалений до вашого локального github / bitbucket / XX-клону. Тоді натискання на OpenShift еквівалентно відхиленню від OpenShift.
adietisheim

1
Якщо я це розумію, якщо я працюю з openhift, я повинен працювати з репортажем розробки (наприклад, github), і якщо я хочу його розгорнути, просто натисніть на головку openhift HEAD, правда?
Рікардо

1
Варто зауважити, що прапор -f та ssh частина git URL є обома необхідними
Simon H

1
@adietisheim з новим git 2.9 вам потрібно буде додати, --allow-unrelated-historiesоскільки зміна за замовчуванням git не дозволяла об'єднувати непов'язані історії.
Алон Бург

23

Я знаю, що питання є дворічним і відповідь @ adietisheim була прийнята. Мені особисто не подобається об'єднувати репо-відкриту зміну у мій локальний клон, тому що я не хочу змішувати репо OpenShift у головну гілку мого публічного репо.

Припустимо, що ви додали дистанційне користування git remote add openshift <openshift-git-repo-url>, ось що я б робив:

Створіть нове місцеве відділення openshiftна базі masterфілії.

git checkout -b openshift

Ви можете зробити деякі комісії у гілці, openshiftнаприклад конфігурації розгортання програми. Потім натисніть поточну гілку до віддаленого майстра узгодження ref у сховищі OpenShift із прапором, -fщоб перезаписати все у віддаленій masterгілці.

git push openshift master -f

Щоразу, коли я хочу розгорнути свій додаток до OpenShift, я перевіряв би локальну openshiftгілку і зливав masterгілку з нею, а потім примушував натискати на OpenShift, однак, -fможливо, не знадобиться для наступних натискань :

git checkout openshift
git merge --no-ff master
git push openshift master -f

6

З папки проекту ви робіть

git remote add backup user@server:/path/to/git/test.git
git push backup master

Ви можете прочитати Pushing до двох віддалених джерел git з одного сховища та Зміна віддаленого походження git .


git push backup masterдостатньо, вам не потрібно вказувати обидві сторони респекту.

1
Підказка для виходу на 2 git дистанційного - ідеальна. Ви також можете зробити:: git push -u all"все" на віддалений за замовчуванням. Здійснюючи це git push, згодом він підштовхнеться до двох репостів!
Акрам Бен Ейсі

5

Я погоджуюся з відповіддю @ adietisheim: вам потрібно зрозуміти краще git перед тим, як розгорнути з openshift =)

Тепер, навіть якщо ви розумієте git, не обов’язково очевидно, як розгорнути існуюче репо, якщо ваша структура каталогу не відповідає структурі каталогів, необхідній для openhift, і якщо ви хочете зберегти свою стару структуру каталогів.

Для цього у мене є такі поради:

  • окремі параметри, що розгортаються залежно від тих, які не перебувають у різних файлах. Наприклад, я відокремлюю налаштування бази даних від інших налаштувань на різні файли як:

    • settings_deploy / openshift

    • settings_deploy / localhost

    а потім посилання на ваш тест localhost як щось подібне:

    ln -s settings_deploy/localhost settings_deploy_file
    

    Інший варіант - виявити хоста за допомогою змінних середовища:

    if 'OPENSHIFT_APP_NAME' in os.environ:
        //openshift configurations
    else:
        //localhost
    

    Це трохи простіше, оскільки дозволяє розмістити всі конфігурації в одному файлі. Це трохи менш загально, оскільки якщо будь-хто інший з ваших хостів пропонує OPENSHIFT_APP_NAMEзмінну середовища (навряд чи для цього), метод порушується. У будь-якому разі, ви все одно повинні чітко розділяти, що залежить від розгортання, а що ні.

  • створити локальний каталог розгортання

  • клонуйте в нього початковий шаблон відкритого переміщення

  • створити сценарій розгортання, який:

    • жорсткі посилання на все від вашого старого існуючого локального до їх правильного розташування в

      жорсткі посилання швидко створюють і використовують дуже мало пам'яті

      ви можете використовувати щось на кшталт:

      cp -lrf original_repo_dir deploy_repo_dir

    • зберігайте лише правильний settings_deployфайл у репортажі розгортання:

      cd deploy_repo

      mv settings_deploy/openshift settings_deploy_file

      rm -r settings_deploy

    • силовий поштовх:

      cd deploy_repo

      git push -f origin master

    • очистити РЕПО розгортання:

      git reset --hard HEAD

      git clean -df

для тих, хто зацікавлений у розгортанні django, я маю приклад на своєму github , зокрема ознайомтеся зі deploy.shсценарієм та проектом, projects/elearnякий він розгортає.


4

Ви повинні мати можливість передати наявне сховище Git в конвеєр активів через

rhc create-app $APPNAME ruby-1.9 --from-code $GIT_LOCATION

Потім віддалене сховище Git доставляє початкову програму для OpenShift.

Як друга можливість, ви можете пропустити створення локального сховища OpenSHift Git через

rhc create-app $APPNAME ruby-1.9 --no-git

а потім скористайтеся описаними вище кроками для об'єднання віддаленого сховища Git OpenShift у ваше локальне сховище Git.


4

Відповідь Моханда ідеальна, але я хотів би підсумувати повне рішення, на випадок, якщо хтось потребує цього:

Щоб використовувати ваше github repo в якості репо-оператора Openshift, зараз немає ідеального рішення, тому що Openshfit використовує git гачки для запуску розгортання або перерозподілу на основі ваших зобов'язань. Однак найрозумнішим способом було б використовувати 2 репости (один відкритий зсув і той, що працює з вашим Github), щоб одночасно просунути код.

Для цього: Додайте пульт з назвою "всі" та додайте до нього 2 push-адреси.

git remote add all ssh://23456781234567@yourapp-namespace.rhcloud.com/~/git/yourapp.git
git remote set-url openshift-git-repo --push --add ssh://23456781234567@yourapp-namespace.rhcloud.com/~/git/yourapp.git
git remote set-url github-repo --push --add git@github.com:youruser/yourapp.git

Потім встановіть пульт дистанційного імені "all" як пульт дистанційного керування за замовчуванням:

git push -u all

Щоб здійснити та натиснути свій код, дійте, як зазвичай: він надіне два пульти та розгорнеться на OpenShift

git add .
git commit -m "my commit"
git push

І дивіться результат:

[master 3fc96b2] my commit
 1 file changed, 2 deletions(-)
MyLaptop:myapp User$ git push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 291 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
To git@github.com:User/myapp.git
   a036a44..3fc96b2  master -> master
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 291 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Stopping PHP 5.4 cartridge (Apache+mod_php)
remote: Waiting for stop to finish
remote: Waiting for stop to finish
remote: Building git ref 'master', commit 3fc96b2
remote: Preparing build for deployment
remote: Deployment id is 9037d37a
remote: Activating deployment
remote: Starting PHP 5.4 cartridge (Apache+mod_php)
remote: Application directory "/" selected as DocumentRoot
remote: -------------------------
remote: Git Post-Receive Result: success
remote: Activation status: success
remote: Deployment completed with status: success
To ssh://23456789@myapp-namespace.rhcloud.com/~/git/myapp.git/
   a036a44..3fc96b2  master -> master
MyLaptop:myapp User$

Сподіваюся, це допомагає


У вас помилка. Ви можете мати кілька сховищ, але обидва вони не можуть бути названі "походженням". Вони повинні бути унікальними, як: походження і origin2
Eric P

використовуючи цю реалізацію , але я отримав повідомлення про помилку , що говорить , не такий віддалений «OpenShift-ГИТ-репо» .. я думаю , що є недостатнє за сценарієм вище ..
Арман Ortega

2

Існує спосіб зробити те, що ви хочете, тобто пропустіть репо на Openshift. Що вам потрібно зробити, це налаштувати джинкіни, і вони опитують ваше власне сховище.

Тут є посилання, яке пояснює, як його встановити з нуля: http://blog.anthavio.net/2014/01/deploy-to-openshift-from-github.html


1

У мене виникли проблеми з розгортанням наявного сховища коду до Openshift. У моєму конкретному контексті, де я намагався розгорнути tomcat webapp, файли конфігурації tomcat Openshift, що входять у папку .openshift, були вирішальними.

Для мене це виправлено - включення папки .openshift у моє існуюче дерево-джерело, а також включення профілю openhift у мій файл maven pom.xml.

Це велика ймовірність того ж, що відбудеться об'єднанням вашого сховища з новим відкритим зсувом вище за течією. Для мене це "чому" за наступним реченням у великій відповіді Адетісгайма:

"Щоб потім можна було виштовхнути код з вашого локального git repo до openhift, спочатку вам слід об'єднати вашу репосту openhift з локальним клоном bitbucket."

У моєму випадку це об'єднання було потрібно для отримання файлів конфігурації з каталогу .openshift. Мені потрібно було довго розібратися, оскільки натискання без каталогу .openshift все-таки змусило моє додаток скластись та розгорнутись. Єдиною поведінкою, яку я бачив, був звіт про відсутні файли jsp, який змусив мене думати, що проблема пов'язана з моєю власною конфігурацією web.xml та сервлетів.



0

Якщо ви використовуєте Java, то існує альтернативний підхід. Але навіть у такому підході ви все одно будете використовувати git сховище OpenShift. Репозиторій git, який надає OpenShift, - це те, як ви надаєте OpenShift код, розгорнуті (і):

Ви можете - замість того, щоб ввести код у репортажі OpenShift git - просто надати йому свій файл війни. Ви клонуєте git repo OpenShift до своєї локальної машини. Потім ви будуєте війну з джерела свого додатка і поміщаєте цю війну в папку розгортань у межах вашого OpenShift git repo (клон). Потім ви додаєте, фіксуєте та натискаєте свій локальний клон на OpenShift. Після успішного виконання натискання, JBoss AS7 вибере вашу війну і розгорне її.


0

БЕРЕГО ЛЕГКО!

крок 1: Створіть додаток. За допомогою вашого улюбленого методу (від gitRepository, попереднього виробника Openshift тощо). якщо ви використовуєте консольний метод
крок 2: rhc git-clone nameApp
крок 3: rhc app-configure nameApp --auto-deploy
крок 4: ПРАВИТИ!


Це добре, але це було просто не відповіддю на питання :)
Янош Вінчеллер
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.