Внесение вклада в GitLab CI

Этот гайд подробно объясняет, как вносить вклад в GitLab CI.

Правила использования трекера задач

Поиск задач перед тем, как отправить свою, чтобы проверить наличие аналогичной проблемы. Вероятнее всего, кто-то уже столкнулся с такой же проблемой. Выразите своё одобрение с помощью :+1: и/или присоединитесь к обсуждению. Пожалуйста, отправьте задачи в следующем формате (в качестве первого сообщения):

1. Краткое описание: Опишите вашу проблему одним предложением (что пошло не так, что вы ожидали получить).
2. Шаги для воспроизведения: Как можно воспроизвести эту проблему.
3. Ожидаемое поведение: Подробно опишите вашу проблему.
4. Наблюдаемое поведение.
5. Релевантные логи и/или скриншоты: Пожалуйста, используйте блоки кода (```) для форматирования вывода консоли, логов и кода, поскольку это очень трудно читать иначе.
6. Возможные решения: Если возможно, предоставьте ссылку на строку кода, которая может быть ответственной за проблему.

Объединённые запросы

Мы рады принимать объединённые запросы с исправлениями и улучшениями для кода, тестов и/или документации GitLab. Функции, для которых мы особенно хотели бы видеть объединённые запросы, указаны со статусом "принимает объединённые/объединённые запросы" на нашем форуме обратной связи, но также приветствуем любые улучшения.### Правила объединённых запросовЕсли возможно, пожалуйста, отправьте объединённый запрос с исправлением или улучшением, включая тесты. Если вы не знаете, как исправить проблему, но можете написать тест, который её обнаруживает, мы примем это тоже. В общем, исправления ошибок, включающие регрессионный тест, обычно быстро объединяются, тогда как новые функции без правильных тестов менее вероятно получат своевременную обратную связь. Процесс создания объединённого запроса следующий:

1. Создайте вилку проекта на GitLab Cloud
2. Создайте ветку с новой функцией
3. Напишите тесты и код
4. Добавьте ваши изменения в CHANGELOG
5. Если у вас несколько коммитов, объедините их в один коммит с помощью squash
6. Отправьте коммит в вашу вилку
7. Подайте запрос на слияние (merge request, MR)
8. Заголовок MR должен описывать изменения, которые вы хотите внести
9. Описание MR должно содержать мотивацию ваших изменений и метод, которым вы достигли этих изменений
10. Если MR меняет пользовательский интерфейс, он должен включать скриншоты до и после изменений
11. Ссылайте на связанные issues и/или обратную связь из описания запроса на слияние и оставьте комментарий на них с обратной ссылкой на MRБудьте готовы отвечать на вопросы и внедрять отзывы даже если они приходят неделями или месяцами после вашей подачи MR. Пожалуйста, сделайте изменения в одном MR как можно меньше. Если вы хотите внести крупную функцию, очень внимательно рассмотрите минимально жизнеспособное изменение. Можно ли разделить функциональность? Можно ли отправить только код бэкэнда/API? Можно ли начать с очень простого UI? Чем меньше MR, тем больше вероятность его принятия. После этого вы можете отправить ещё несколько MR для улучшения.Мы примем запросы на слияние, если:

• Код имеет правильные тесты и все тесты проходят (или это тест, который выявляет ошибку в существующем коде)
• Он может быть слит без проблем (если нет, пожалуйста используйте: git rebase master)
• Он не нарушает ни одну существующую функциональность
• Это качественный код, соответствующий руководствам по стилю Ruby и Rails и лучшим практикам
• Это не является "ловушкой" для слияния, а скорее исправляет конкретную проблему или реализует конкретную функцию
• Он поддерживает чистый и хорошо структурированный базовый код GitLab
• Мы считаем, что такой функциональностью будут пользоваться другие пользователи
• Это одно изменение (пожалуйста используйте git rebase -i, чтобы объединить изменения)