Гілки

Перегляд Гілки надає огляд різних гілок у вашому репозиторії.

Етапи

Odoo.sh пропонує три різні етапи розгалуження:

• Виробництво

• Проміжна

• Розробка

Ви можете змінити стадію гілки, перетягнувши її під потрібну стадію.

Примітка

• Гілки розробки можна переміщувати під Проміжна розробка. Якщо ви спробуєте перемістити гілку розробки під Виробництво, з’явиться попередження, яке пояснює, що ви можете мати лише одну гілку виробництва на один проект.

• Гілки для проміжної розробки можна переміщувати під Розробка, але неможливо переміщувати їх під Виробництво.

• Гілку production можна перемістити лише до Розробка. Якщо ви спробуєте перемістити її до Проміжна розробка, ви зможете виконати лише злиття. Зверніться до розділу злиття для детального пояснення цього процесу.

Виробництво

Виробничагілка містить код, який використовується для запуску виробничої бази даних. Може бути лише одна виробнича гілка.

Коли ви надсилаєте новий коміт до цієї гілки, виробничий сервер оновлюється виправленим кодом і перезапускається.

Якщо зміни вимагають оновлення модуля, наприклад, зміни вигляду форми, і ви хочете, щоб оновлення виконувалося автоматично, ви можете збільшити номер версії модуля в його файлі маніфесту (__manifest__.py). Потім платформа виконує оновлення, під час якого екземпляр буде тимчасово недоступний з причин технічного обслуговування.

Цей метод еквівалентний оновленню модуля за допомогою меню Додатки або перемикача -u у командному рядку.

Примітка

• Якщо зміни перешкоджають перезавантаженню сервера або якщо оновлення модуля завершується невдачею, сервер автоматично повертається до попередньої успішної версії коду, а база даних повертається до попереднього стану. Отримайте доступ до журналу невдалого оновлення для усунення несправностей.

• Демонстраційні дані не завантажуються, оскільки вони не призначені для використання у виробничій базі даних. Модульні тести не виконуються, оскільки це збільшило б час недоступності виробничої бази даних під час оновлення.

Odoo.sh автоматично створює резервні копії вмробничої бази даних. Він зберігає сім щоденних, чотири щотижневих та три щомісячні резервні копії. Кожна резервна копія містить дамп бази даних, сховище файлів (вкладення та двійкові поля), журнали та сесії.

Попередження

Під час використання пробних проектів, виробнича гілка та всі проміжні гілки автоматично повертаються до стадії розробки через 30 днів.

Проміжний

Проміжні гілки призначені для тестування нових функцій з використанням виробничих даних без шкоди для фактичної виробничої бази даних тестовими записами. Вони створюють нейтралізовані дублікати виробничої бази даних.

Нейтралізація вимикає:

• Заплановані дії

  Примітка

  Щоб протестувати їх, активуйте їх вручну або знову ввімкніть. Майте на увазі, що платформа активуватиме їх рідше, якщо ніхто не використовує базу даних, щоб заощадити ресурси.

• Вихідні ел. листи

  Примітка

  Натомість їх перехоплюють за допомогою ловця пошти. У вашому проєкті Odoo.sh передбачено інтерфейс для перегляду електронних листів, надісланих базою даних. Таким чином, електронні листи не надсилаються вашим контактам.

• IAP служби

• Постачальники платіжних послуг та конектори доставки

  Примітка

  Вони переведені в тестовий режим.

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

Примітка

Модульні тести не виконуються. Вони спираються на демонстраційні дані, які не завантажуються у виробничу та проміжну бази даних. Якщо Odoo почне підтримувати запуск модулів без демонстраційних даних, Odoo.sh розгляне можливість запуску тестів на проміжних базах даних.

Резервні копії проміжних баз даних не створюються автоматично. Тим не менш, ви можете відновити резервну копію робочої бази даних у проміжній гілці для тестування або для ручного відновлення даних, випадково видалених з робочої бази даних. Можна створювати резервні копії проміжних баз даних вручну.

Попередження

Бази даних, створені для проміжних гілок, розраховані на термін служби до трьох місяців. Після цього їх можна автоматично заблокувати без попереднього повідомлення. Тільки перебудова гілки дозволить вам знову використовувати цю конкретну гілку.

Розробка

Гілки розробки створюють нові бази даних, використовуючи демонстраційні дані для запуску модульних тестів. Встановлені модулі – це ті, що включені до гілки. Ви можете змінити цей список модулів для встановлення у налаштування проекту.

Під час надсилання коміту до гілки розробки запускається новий сервер зі створеною з нуля базою даних, а гілка оновлюється. Демонстраційні дані завантажуються, і модульні тести виконуються за замовчуванням, щоб перевірити, чи зміни не порушують роботу жодної з тестованих функцій. Ви можете вимкнути тести або дозволити запуск певних тестів з користувацькими тегами, перейшовши до налаштувань гілки.

Подібно до проміжних гілок, ел/ листи не надсилаються, а перехоплюються ловцем пошти, а заплановані дії не запускаються, доки база даних не використовується.

Резервні копії баз даних розробників не створюються автоматично, а ручне резервне копіювання неможливе.

Попередження

Бази даних, створені для гілок розробки, розраховані на термін служби приблизно три дні. Після цього їх можна автоматично переміщувати у сміттєвий резерв, щоб звільнити місце для нових баз даних без попереднього повідомлення.

Об’єднання гілок

Ви можете об’єднати свої гілки, перетягуючи їх одна в одну.

Щоб протестувати зміни гілок розробки з даними виробничої, ви можете:

• Об’єднайте гілку розробки з гілкою проміжної обробки, перетягнувши її на потрібну гілку; або

  

• Перетягніть гілку розробки в розділ Проміжна, щоб зробити її проміжною гілкою.

  

Коли зміни будуть готові до виробничої, перетягніть проміжну гілку до виробничої, щоб об’єднати та розгорнути їх.

Примітка

• Ви можете безпосередньо об’єднати гілки розробки з гілкою виробництва. Однак зміни не будуть перевірятися на відповідність даним виробництва через проміжну гілку, тому існує вищий ризик виникнення проблем у базі даних виробництва.

• Ви можете об’єднувати гілки розробки одна в одну, а також гілки проміжного розміщення одна в одній.

• Ви також можете використовувати git merge безпосередньо на вашій робочій станції для об’єднання гілок. Odoo.sh отримує сповіщення, коли нові версії надсилаються до ваших гілок.

Злиття проміжної гілки з виробничою гілкою об’єднує лише вихідний код. Будь-які зміни, внесені до проміжної бази даних, не передаються до виробничої бази даних. Однак, якщо ви зміните код у репозиторії, він буде передано до виробничої гілки під час злиття.

Якщо ви тестуєте зміни конфігурації в проміжних гілках і хочете, щоб їх застосували до продакшн-гілки, вам потрібно зробити одне з наступного:

• Запишіть зміни конфігурації у файли даних XML, щоб перезаписати конфігурацію або представлення за замовчуванням у гілці, а потім збільште версію модуля в його маніфесті (__manifest__.py), щоб ініціювати оновлення модуля під час об’єднання проміжної гілки з виробничою гілкою.

  Примітка

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

• Передайте їх вручну з проміжної бази даних до виробничої, скопіювавши та вставивши.

Вкладки

Історія

Вкладка Історія надає огляд історії гілок:

• Повідомлення комітів та їхні автори

• Різні події, пов’язані з платформою, такі як зміни етапів, імпорт бази даних та відновлення резервних копій

Статус у верхньому правому куті кожної події вказує на поточну операцію з базою даних (наприклад, встановлення, оновлення, імпорт резервної копії) або її результат (наприклад, тестовий зворотний зв’язок, успішний імпорт резервної копії). Якщо операція успішна, з’являється кнопка Підключитися, яка дозволяє отримати доступ до бази даних.

Листи

Вкладка Пошта містить перехоплювач пошти, який надає огляд електронних листів, надісланих базою даних.

Примітка

Ловець пошти доступний для гілок розробки та проміжного використання. Електронні листи з робочої бази даних фактично надсилаються та не перехоплюються лотком пошти.

Оболонка

Вкладка Shell надає доступ до контейнера через оболонку.

Натискання Shell відкриває нову вкладку браузера, де можна виконувати основні команди Linux (ls, top). Ви можете відкрити оболонку бази даних, запустивши psql.

Порада

Ви можете відкрити кілька вкладок shell одночасно та упорядкувати їхнє розташування, перетягуючи їх.

Примітка

• Оболонки виробничих екземплярів виділені червоним кольором, щоб підкреслити небезпеку безпосереднього маніпулювання виробничими екземплярами, тоді як оболонки проміжних/розробницьких екземплярів виділені жовтим кольором.

• Тривалі екземпляри оболонки/сеанси оболонки в режимі очікування можна завершити в будь-який час, щоб звільнити ресурси.

Команди

Ось огляд корисних команд, які можна запустити в терміналі бази даних Odoo.sh:

• odoo-bin shell: відкрити shell Odoo

• odoo-update: для оновлення модулів у базі даних

• odoosh-restart: для перезапуску сервісів Odoo.sh (http або cron)

• odoosh-storage: для перевірки використання сховища файловою системою контейнера вашого екземпляра

• psql: відкрити shell бази даних

• mutt: перевіряти, як відображаються електронні листи в текстових клієнтах (проміжні та розробницькі екземпляри)

• lnav ~/logs/odoo.log: для навігації у файлі odoo.log вашого екземпляра

• ncdu: запустити аналізатор використання диска з інтерактивним інтерфейсом

• grep: для фільтрації та пошуку інформації в журналі або файлах конфігурації

Редактор

Натискання Редактор відкриває нову вкладку браузера для доступу до інтегрованого онлайн-середовища розробки (IDE) для редагування вихідного коду. Ви також можете відкрити термінали, консолі Python та консолі оболонки Odoo.

Ви можете відкрити кілька вкладок і перетягнути їх, щоб упорядкувати макет на свій розсуд.

Перегляньте також

Документація онлайн-редактора.

Моніторинг

Вкладка Монітор відображає різні показники моніторингу продуктивності поточної збірки.

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

Примітка

• У технічних журналах завжди використовується формат UTC. Щоб аналізувати ці журнали разом із показниками моніторингу, переконайтеся, що в інструменті моніторингу вибрано UTC.

• Так само, надсилаючи запит на підтримку, переконайтеся, що надана вами інформація базується на часовому поясі UTC, оскільки Odoo використовує цей часовий пояс для дослідження проблем із продуктивністю.

Інформація періодично агрегується. У такому разі відображається синя пунктирна лінія разом із тегом Дата агрегації. Це означає, що дані до цієї дати будуть виглядати вирівняними порівняно з даними після цієї дати. Тому під час використання інструменту моніторингу рекомендується зосередитися на нещодавніх подіях, щоб отримати якомога детальнішу інформацію.

Примітка

Пунктирні лінії інших кольорів допомагають вам зрозуміти інші зміни під час збірки (імпорт бази даних, надсилання даних у git тощо).

Порада

На кожному графіку у верхньому лівому куті відображається значок 𝕚 (information). Наведіть на нього курсор миші, щоб отримати докладнішу інформацію про те, що відображає графік.

Метрики

Система

Графік Пам’ять відображає інформацію про споживання пам’яті:

• Контейнер пам’яті представляє робочі процеси Odoo та процеси-контейнери.

• Пам’ять postgresql представляє базу даних.

Графік CPU відображає інформацію про споживання процесора:

• CPU http представляє робочі процеси Odoo.

• CPU cron/mail представляє заплановані дії та вхідні електронні листи.

• CPU postgresql (процеси бази даних)

• CPU other представляє веб-оболонки, редактор тощо.

Графік Сховище відображає інформацію про використаний обсяг пам’яті:

• Контейнер представляє сховище файлів, файли журналів та файли користувача.

• Postgresql представляє базу даних та індекси.

HTTP

Графік Запити відображає інформацію про кількість HTTP-запитів за секунду:

• Успішні HTTP представляє успішні запити.

• Помилки HTTP позначає невдалі запити (перевірте odoo.log).

• Обмежена швидкість HTTP означає відхилені запити, можливо, через брак робочих процесів.

Графік Одночасні запити (макс.) відображає максимальну кількість одночасних HTTP-запитів за секунду.

Примітка

Кількість одночасних запитів, які можна обробляти, визначається обробниками бази даних. Важливо мати достатню кількість обробників для обробки всіх вхідних запитів у міру їх надходження. Однак, наявність додаткових обробників понад цю кількість не покращує швидкість обробки запитів.

Середній час відповіді відображає середній час відповіді на HTTP-запити (у мілісекундах).

Листи

Графік Вхідні відображає дані про щоденну кількість вхідних електронних листів:

• Отримані електронні листи відображає успішно отримані електронні листи.

• Отримані електронні листи, не отримані означає електронні листи, отримані безуспішно.

Графік Вихідні відображає дані про щоденну кількість вихідних електронних листів:

• Надіслані електронні листи відображає успішно надіслані електронні листи.

• Надіслані електронні листи, відхилені означає електронні листи, які не вдалося надіслати.

Журнали

Вкладка Журнали пропонує перегляд журналів вашого сервера в режимі реального часу.

Доступні різні журнали:

• pip.log: встановлення залежностей Python

• install.log: встановлення бази даних (для гілок розробки, тести включені)

• odoosh-import-database.log: останній імпортований дамп процесу

• odoo.log: запущений сервер

• update.log: оновлення бази даних

• pg_slow_queries.log: запити psql, які виконуються надзвичайно довго

• sh_webshell.log: дії, виконані у веб-оболонці

• sh_editor.log: дії, виконані в редакторі

• neutralize.log: нейтралізація бази даних (лише для проміжної)

Коли до журналів додаються нові рядки, вони відображаються автоматично. Якщо прокрутити вниз, браузер прокручуватиме автоматично щоразу, коли додається новий рядок.

Ви можете призупинити процес отримання журналів, натиснувши кнопку (pause) у верхньому правому куті. В іншому випадку процес зупиниться через п’ять хвилин. Ви можете перезапустити його, натиснувши кнопку (play).

Резервні копії

На вкладці Резервні копії перелічено доступні резервні копії для завантаження та відновлення, а також ви можете виконати резервне копіювання вручну та імпортувати базу даних.

Резервне копіювання виробничої бази даних автоматично створюється щодня. Зберігається сім щоденних, чотири щотижневі та три щомісячні резервні копії. Кожна резервна копія містить дамп бази даних, сховище файлів (вкладення та двійкові поля), журнали та сеанси.

Примітка

Ви можете звернутися до орієнтовного планування автоматичного резервного копіювання, щоб краще зрозуміти, як працює система. Цей файл оновлюється щодня, беручи поточний день за відправну точку.

Резервні копії баз даних для проміжних та розробницьких версій не створюються автоматично. Однак ви можете відновити резервну копію робочої бази даних у ваших проміжних гілках для цілей тестування або вручну відновити дані, випадково видалені з робочої бази даних.

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

Виділені сервери резервного копіювання зберігають ті самі резервні копії, а також три додаткові щомісячні резервні копії. Щоб відновити або завантажити одну з цих щомісячних резервних копій, зверніться до служби підтримки Odoo <https://www.odoo.com/help>`_.

Під час об’єднання коміту, що оновлює версію одного або кількох модулів (у __manifest__.py), або їхніх пов’язаних залежностей Python (у requirements.txt), Odoo.sh виконує автоматичне резервне копіювання (позначене типом Update у списку), оскільки або контейнер буде змінено шляхом встановлення нових pip-пакетів, або сама база даних буде змінена з подальшим оновленням модуля. У цих двох випадках резервне копіювання запускається, оскільки це може щось зламати.

Якщо об’єднаний коміт не оновлює версію модуля або пов’язаних залежностей, то Odoo.sh не запускає резервне копіювання, оскільки ні контейнер, ні база даних не змінюються; тому платформа вважає це достатньо безпечним. Як додатковий запобіжний захід, ви можете зробити резервне копіювання вручну перед зміною вихідних кодів.

Мета ручного резервного копіювання - створити певний знімок робочих або проміжних баз даних (недоступний для розробки). Вони залишаються доступними протягом семи днів. Однак існує обмеження в п’ять щоденних ручних резервних копій.

Етап	Автоматичне резервне копіювання	Ручне резервне копіювання
Виробництво	Так (до 3 місяців)	Так (3 дні)
Проміжний	Ні	Так (3 дні)
Розробка	Ні	Ні

Функція Імпорт бази даних приймає архіви баз даних з:

• стандартний менеджер баз даних Odoo (доступний для локальних серверів Odoo у розділі /web/database/manager)

• менеджер баз даних Odoo Online

• вкладка Odoo.sh Резервні копії (за допомогою кнопки (Параметри завантаження))

• вигляд Odoo.sh Збірки (натиснувши Завантажити дамп бази даних)

Оновлення

Вкладку Оновлення можна використовувати для оновлення виробничих та проміжних гілок дійсних проектів. Для отримання додаткової інформації про процес оновлення зверніться до Документація з оновлення.

Інструменти

Вкладка Інструменти містить профайлер коду. Він використовується для запуску сеансу профілювання, записуючи діяльність Odoo воркерів, що працюють в екземплярі, протягом максимум п’яти хвилин. Ви можете завершити сеанс раніше, оскільки запуск інструменту протягом коротшого періоду зменшує кількість шуму у звіті.

Після кожного сеансу створюється інтерактивний графік полум’я, який допоможе вам візуалізувати, як працівники Odoo розподіляють свій час.

Попередження

Запуск профайлера споживає багато ресурсів сервера, тому уникайте його тривалої роботи. Мета полягає в тому, щоб записати певну дію у вашу базу даних.

Налаштування

На вкладці Налаштування перелічено параметри конфігурації, доступні для вибраної гілки. Ці параметри відрізняються для кожного етапу.

Поведінка при нових коммітах

Ви можете змінити поведінку гілки після отримання нового коміту для гілок development та staging.

За замовчуванням гілка development створює нову збірку, а гілка staging оновлює попередню збірку. Це корисно, якщо функція, над якою ви працюєте, вимагає певної конфігурації, оскільки вам не потрібно буде налаштовувати її вручну знову після кожного коміту.

Якщо ви оберете Нова збірка для гілки staging, нова копія збірки для виробництва створюватиметься щоразу, коли надсилається коміт.

Гілка, переміщена з staging до development, автоматично отримує значення Нічого не робити.

Встановлення модуля

Ви можете вибрати, які модулі слід встановлювати автоматично для гілок development.

Щоб змінити поведінку за замовчуванням, зніміть позначку з опції Використовувати за замовчуванням в розділі Поведінка розробки при збірці та виберіть один із наступних варіантів у розділі Встановлення модуля:

• Встановити лише мої модулі (без підмодулів): встановлює лише модулі гілки, за винятком підмодулі. Це параметр за замовчуванням.

• Повна інсталяція (без набору тестів): встановлює модулі гілки, підмодулі та всі стандартні модулі Odoo. Під час запуску повної інсталяції набір тестів вимикається.

• Встановити список модулів: встановлює вказані модулі. Для цього введіть їхні технічні назви та розділіть їх комами (наприклад, управління_продажами, вебсайт,бухгалтер).

Примітка

Якщо тестовий набір увімкнено, встановлення всіх стандартних модулів Odoo може тривати до однієї години.

Набір тестів

За замовчуванням набір тестів для гілок development увімкнено. Ви можете обмежити виконання тестів, ввівши тестові теги та розділивши їх комами (наприклад, custom_tags, at_install,post_install).

Щоб повністю вимкнути набір тестів, зніміть позначку Перевіряти набір тестів для нових збірок.

Версія Odoo

Ви можете змінити версію Odoo для гілок development, наприклад, щоб протестувати оновлений код або розробити функції, поки ваша виробнича база даних перебуває в процесі оновлення до новішої версії, вибравши іншу Версію.

За замовчуванням як Ревізія вибрано Остання, і вихідні коди вашого сервера Odoo оновлюються щотижня автоматично, щоб скористатися останніми виправленнями помилок, покращенням безпеки та продуктивності.

Щоб вибрати певну редакцію, виберіть її за допомогою поля Редакція.

Попередження

Термін дії редакцій дійсний протягом трьох місяців. Ви отримаєте сповіщення електронною поштою, коли наближатиметься дата закінчення терміну дії редакції. Якщо ви не вжили жодних дій після закінчення терміну її дії, поле Редакція автоматично повертається до значення Остання.

Користувацькі домени

Ви можете налаштувати додаткові домени <name>.odoo.com або власні користувацькі домени для всіх типів філій.

Щоб використовувати власний користувацький домен, необхідно:

• Володіти доменним іменем або придбати його.

• Введіть доменне ім’я в розділі Власні домени (наприклад, www.mycompany.com), а потім натисніть Додати домен.

• Налаштуйте доменне ім’я (наприклад, www.mycompany.com) за допомогою менеджера доменних імен вашого реєстратора, встановивши значення запису CNAME, встановлене на доменне ім’я вашої виробничої бази даних (наприклад, mycompany.odoo.com).

Важливо

Голі домени (наприклад, mycompany.com) не приймаються. Їх можна налаштувати лише за допомогою записів A, які приймають як значення лише IP-адреси. Тому голий домен може раптово перестати функціонувати, оскільки IP-адреса бази даних може змінитися (наприклад, після оновлення, збою обладнання, зміни місця розміщення бази даних).

Щоб ваш голий домен (наприклад, mycompany.com) та домен www (наприклад, www.mycompany.com) працювали, необхідно перенаправити голий домен на домен www .com. Більшість менеджерів доменів пропонують спосіб налаштування цього перенаправлення, який зазвичай називають веб-перенаправленням.

HTTPS/SSL

Якщо перенаправлення налаштовано правильно, протягом години автоматично генерується SSL-сертифікат за допомогою Let’s Encrypt, а це означає, що ваш домен буде доступний через HTTPS.

Відповідність SPF та DKIM

Якщо домен ваших адрес електронної пошти використовує протокол автентифікації SPF або DKIM, необхідно авторизувати Odoo як хост-відправник у налаштуваннях доменного імені, щоб підвищити доставляність вихідних електронних листів. Для отримання додаткової інформації зверніться до документації Налаштування записів DNS для надсилання електронних листів у документації Odoo.

Важливо

Якщо Odoo не авторизовано як хост-розсилка, ваші вихідні електронні листи можуть бути позначені як спам.

Команди оболонки

У верхньому правому куті вікна відображається кілька команд оболонки. Команди можна скопіювати за допомогою кнопки буфера обміну, а потім використовувати в терміналі. Крім того, деякі з них можна використовувати безпосередньо з інтерфейсу Odoo.sh.

Клонувати

Команда clone використовується для створення локальної копії вашого репозиторію Git.

Example

git clone --recurse-submodules --branch development [email protected]:my-organization/my-repository.git

• --recurse-submodules для завантаження підмодулів вашого репозиторію

• --branch main для отримання даних до певної гілки репозиторію (наприклад, development)

Примітка

Кнопка run недоступна, оскільки команда використовується для створення локальної копії на вашому комп’ютері.

Fork

Команда fork використовується для створення нової гілки на основі поточної.

Example

git checkout -b main-1 development && git push -u origin development-1

• git checkout -b main-1 main команда для створення нової гілки (наприклад, development-1) на основі поточної гілки (наприклад, development)

• git push -u origin development-1 команда для завантаження нової гілки (наприклад, development-1) до віддаленого репозиторію

З’єднати

Команда merge використовується для об’єднання змін в одній гілці в іншу.

Example

git merge staging-1 && git push -u origin staging

• git merge staging-1 - команда для об’єднання змін поточної гілки з іншою гілкою (наприклад, staging-1)

• git push -u origin staging - команда для завантаження об’єднаних змін до гілки віддаленого репозиторію (наприклад, staging)

SSH

Команда SSH використовується для підключення до збірки за допомогою SSH.

Щоб використовувати команду SSH, спочатку необхідно налаштувати ключ SSH. Для цього:

• Згенерувати новий SSH-ключ.

• Скопіюйте SSH-ключ у буфер обміну.

• На Odoo.sh клацніть свого користувача GitHub у верхньому правому куті та виберіть Профіль.

  

• Вставте ключ SSH у поле Додати ключ вручну та натисніть Додати.

  

Example

ssh 25004381@my-user-my-repository-staging-25004381.dev.odoo.com

• 25004381 ID збірки

• my-user-my-repository-staging-25004381.dev.odoo.com – домен, що використовується для підключення до збірки

За умови, що у вас є необхідні права доступу до проєкту, вам буде надано SSH-доступ до збірки.

Примітка

Тривалі SSH-з’єднання не гарантуються. Неактивні з’єднання можна роз’єднати, щоб звільнити ресурси.

Підмодуль

Команда submodule використовується для додавання гілки з іншого репозиторію до вашої поточної гілки як підмодуля.

Перегляньте також

Документація підмодулів

Example

git submodule add -b master <URL> <PATH> && git commit -a && git push -u origin staging

• git submodule add -b master <URL> <PATH> команда для додавання певної гілки (наприклад, master) репозиторію (<URL>) як підмодуля за вказаним шляхом (<PATH>) у вашій поточній гілці.

• git commit -a - команда для фіксації всіх поточних змін

• git push -u origin staging - команда для завантаження змін поточної гілки (наприклад, staging) до віддаленого репозиторію.

Видалити

Команда delete використовується для видалення гілки з вашого репозиторію.

Примітка

Після видалення гілки її неможливо відновити, якщо не існує резервної копії. Резервні копії проміжних гілок не створюються автоматично, але їх можна створити вручну. Резервні копії розробницьких гілок створити не можна.

Example

git push origin :staging && git branch -D staging

• git push origin :staging - команда для видалення певної гілки (наприклад, staging) у віддаленому репозиторії

• git branch -D staging - команда для видалення певної гілки у вашій локальній копії репозиторію

Попередження

Перш ніж видаляти гілку, зверніться до розділу Резервні копії, щоб краще зрозуміти, як вони працюють і коли слід створювати резервну копію вручну.