Защита веток от изменений с использованием масок

Чтобы обезопасить ветки от случайного удаления или изменения, их можно защищать. Этот механизм, среди прочего, позволяет разрешать или запрещать доступ к веткам на запись в зависимости от прав пользователей — например, можно не давать рядовым разработчикам пушить или мержить в production- и release-ветки.

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

Например, если вы поставите защиту на маску release-*, все ветки, имя которых начинается с release-, автоматически станут защищенными. При разработке GitLab мы используем эту фичу для защиты наших стабильных веток, применяя маску *-stable.

Мерж в защищенные ветки

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

В предыдущих версиях GitLab пользователям группы ‘Developer’ автоматически было разрешено пушить в защищенные ветки. Начиная с версии 8.10 вы можете независимо давать членам группы Developer права отдельно на пуш и отдельно на мерж.

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

Сюда можно добавить еще и функциональность подтверждений (approvals) из Enterprise Edition, которая позволяет в обязательном порядке требовать ревью от нескольких людей перед принятием изменений. В этом случае мерж-реквест должен быть просмотрен несколькими разработчиками, но принять его тем не менее сможет любой пользователь из группы Developer

Подробнее о защищенных ветках

Улучшенные дифы

Вне зависимости от того, пишете ли вы код, делаете ли код-ревью, или вообще работаете не с кодом, а с каким-то другим текстовым контентом, скорее всего вам приходится много работать с диффами. Очень желательно, чтобы диффы работали быстро и были удобными. В GitLab 8.10 диффы стали рендериться значительно быстрее и научились нескольким интересным штукам.

Более удобные Side-by-Side Diffs

Мы улучшили работу side-by-side diffs, и теперь они показывают изменения в еще более наглядном виде.

Inlinе-диффы

Есл изменения затрагивают только часть строки, мы покажем вам именно ее измененную порцию (а не строку целиком):

Схлапываемые диффы

Теперь вы можете схлапывать диффы, кликая на имя файла. Это поможет вам удобным образом просматривать изменения файл за файлом.

Большие диффы (> 10kb) будут всегда показываться схлопнутыми (но вы в любой момент можете развернуть их). Это должно здорово помочь, если вам постоянно приходится просматривать много больших изменений в большом количестве файлов

Ручные действия для запуска конвеерных задач (pipeline jobs)

Конечно же, вы уже настроили конвейер (pipeline) для Continuous Integration / Continuous Delivery? Использовать такой автоматический конвейер для развертывания на production может быть не самой лучшей идеей. Автоматическое развертывание на staging — вполне нормальная практика, но перед переносом кода в production лучше все-таки провести хотя бы несколько ручных тестов, чтобы окончательно убедиться, что всё работает нормально.

Теперь вы можете задавать активируемые вручную условия для развертывания в production. Опция when: manual добавит в веб-интерфейс новое действие, которое нужно будет активировать вручную — и конвейер продолжит выполнение только после этого ручного действия. Например, ваш релиз-менеджер нажмет эту кнопку после того, как вручную удостоверится, что на staging все работает нормально. Любая задача (job) в вашем конвейере может быть помечена опцией when: manual.

Эти действия также отображаются в окружениях (environments), чтобы вам было проще переводить сборки из staging в production.

О системе CI/CD в GitLab Окружения (environments) в CI

Многострочный синтаксис для цитат в markdown

Если вы хотите пометить несколько строк в вашем markdown-файле как цитату, вам больше необязательно приписывать к каждой строке >. Теперь для этого есть многострочный синтаксис:

>>>
Весь этот блок будет помечен как цитата.

Независимо от количества строк в нем.

Ура, товарищи!
>>>

Подробнее о GitLab Flavored Markdown

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

Теперь вы можете распределить данные ваших репозиториев по нескольким точкам монтирования (mount points). Просто укажите все необходимые mount points в файле gitlab.rb:

git_data_dirs({
 "default" => "/var/opt/gitlab/git-data",
 "alternative" => "/mnt/nas/git-data"
})

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

Подробнее о множественных точках монтирования

Массовая подписка на тикеты

Теперь вы можете подписываться (и отписываться) на большое количество тикетов одновременно. Это полезно в случаях, если вы хотите с ходу нырнуть в новый проект и быть в курсе всего и сразу, или наоборот, хотите побыть в тишине от постоянных email-уведомлений.

Индивидуальные уровни оповещений для групп

В предыдущей версии (8.9) мы добавили индивидуальные оповещения, чтобы вы получали уведомления только об интересующих вас проектных событиях.

В GitLab 8.10 вы можете управлять этими настройками для групп проектов, выставляя одинаковые настройки оповещения сразу для нескольких проектов (не забывайте, что индивидуальные настройки проекта имеют приоритет над групповыми).

Ticket-based Kerberos authentication (доступно только для Enterprise Edition)

До версии 8.10 пользователям GitLab, желающим использовать аутентификацию через Kerberos, приходилось вводить логин и пароль своего Kerberos-аккаунта на странице входа в GitLab. С версии 8.10 GitLab Enterprise Edition позволяет пользователям Kerberos входить в GitLab без ввода логина и пароля — теперь достаточно просто нажать на кнопку “Kerberos Spnego” на странице входа.

Это стало возможным благодаря новому OmniAuth-провайдеру для SPNEGO-аутентификации через Kerberos. Этот провайдер использует наработки института ядерных исследований CERN, с помощью которых в GitLab стало возможно делать git clone с использованием ticket-based аутентификации через Kerberos.

Если браузер пользователя «понимает» протокол Kerberos, а сам пользователь имеет на своей машине валидный Kerberos ticket, то браузер автоматически залогинится в GitLab, ничего не спрашивая у пользователя.

Подробная информация о настройке ticket-based аутентификации через Kerberos для GitLab Enterprise Edition доступна в соответствующем разделе документации.

В следующем релизе мы уберем password-based аутентификацию через Kerberos, так что если вы пользуетесь ей, мы рекомендуем вам как можно скорее перейти на ticket-based вариант.

Подсветка синтаксиса

Подсветка синтаксиса в GitLab 8.10 стала еще лучше.

Мы обновили rouge с версии 1.11.1 до 2.0.5, и в процессе этого обновления добавили новые лексеры и пофиксили несколько багов. Теперь у нас появилась подсветка для Docker, F#, IDL, а уже имевшаяся подсветка для praat, JavaScript, Java, C#, Shell, Liquid, Tulip, Markdown, Ruby, Python and YAML стала еще краше!

Кстати, теперь вы можете переопределять «угадывание» языка для подсветки и выставлять его явно с помощью записи в файле .gitattributes.

Все подробности — в соответствующей документации.

Запрет на запрос доступа

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

Улучшенная интеграция со Slack

GitLab теперь может оповещать вас о разных проектных событиях через Slack — будь то комментарий к тикету, создание нового мерж-реквеста или сломавшаяся сборка.

Slack service теперь позволяет вам настроить, в какой Slack-канал будет приходить сообщение о каждом событии.

Подробнее о Slack Service можно почитать вот тут

Новые эмодзи!

Мы обновились до версии gemojione за 2016 год, и теперь эмодзи стало еще больше.

Черные списки для доменных имен

Теперь можно вносить доменные имена в черный список, и почтовые адреса с этих доменов не смогут регистрироваться в вашем инстансе GitLab. Настройки, связанные с черным списком, находятся в панели администратора.

Почитать об этом можно здесь

Включение и выключение протоколов доступа для Git

Теперь вы можете независимо управлять протоколами доступа к Git: вы можно разрешить доступ к репозиторию только через HTTP, только через SSH или одновременно через HTTP+SSH

Подробнее

Отображение видео в тексте

Если в тексте тикета, комментария или мерж-реквеста содержится ссылка на видео, то GitLab отобразит этот видеоролик прямо в тексте.

Подробнее о GitLab flavored markdown

Предупреждения (warnings) при сборке

Как вы знаете, CI-конвейер можно настроить таким образом, чтобы ошибки при выполнении каких-то задач (jobs) в нем не считались фатальными. При возникновении таких ошибок CI-конвейер выводит предупреждения (warnings). В GitLab 8.10 эти предупреждения будут видны вам в том мерж-реквесте, который их породил

Статистика использования (только для GitLab Enterprise edition)

Чтобы лучше понять, как именно клиенты используют GitLab, 8.10 EE регулярно отправляет анонимную статистическую информацию на сервера GitLab, Inc. Если идея вам не по душе, отключите эту опцию на странице “Application settings” (на этой же странице вы видно, какие данные будут отправлены на наш сервер.

Улучшение производительности

От релиза к релизу GitLab становится лучше и лучше по всем параметрам — и в том числе и по быстродействию. В этом месяце мы ускорили отображение тикетов в 2-2.5 раза и диффов на треть:

Для интересующихся — вот список значительных изменений в версии 8.10 и ссылки на соответствующие мерж-реквесты.

Backend

• HAML has been replaced with Hamlit to reduce memory usage and rendering timings of views
• Certain Git operations are now cached when finding CI pipelines
• Various Git operations on project dashboards are now cached, reducing the time spent in Git whenever the caches exist
• Git operations related to viewing trees of files are only executed when necessary
• The various Markdown reference parsers now re-use SQL queries when used multiple times in the same request, reducing the total number of executed SQL queries
• The column projects.pushes_since_gc is only updated at most once per minute, reducing the number of writes to the projects table
• Checking if an avatar is present no longer hits the underlying storage engine, reducing the time it takes to check if an avatar is present
• Checking if a user has access to a single project has been optimised
• The queries used to get merge request closing/merging events are now cached per request
• The presence of an external wiki is now cached on database level
• Performance of automatically generating links in Markdown has been improved
• Checking whether to show a system note has been optimized
• The maximum access badge for each author of a comment is now cached to prevent multiple lookups for the same author

Frontend

• Rendering of diffs has been improved by only rendering certain UI elements when necessary
• Page specific JS loading has been implemented in a better way, reducing the amount of JS to load per page
• Cropper.js has been separated from the main JavaScript file and only load Cropper.js when necessary
• The projects dropdown now only sends the data it needs, reducing the time it takes to load the data
• Discussion notes are not rendered when the diff tab is requested using Ajax
• The code used to check which issues are closed by a merge request is only called when necessary

Monitoring

• Sidekiq latency is now tracked
• Redis cache hits and misses are now tracked
• The Markdown syntax highlighting filter is instrumented

Runner v1.4

С этого момента runner-релизы будут синхронизированы с ежемесячными основными релизами GitLab. Изменения в этом runner-релизе::

• Use Sentry in GitLab Runner to monitor critical errors
• Improve logging
• Extend support for caching and artifacts for other executors
• Add support for cloning VirtualBox VM snapshots
• Improve support for Docker Machine
• Improve build abort

GitLab Mattermost 3.2

Вместе с GitLab 8.10 поставляется и Gitlab Mattermost 3.2, открытый аналог Slack.

В Mattermost 3.2 были добавлены немецкая локализация, новые эмодзи, улучшенное отображение веток обсуждений (threads), полноэкранный поисковый интерфейс, интеграции с MS Exchange и XMPP, и многое другое.

Кроме того, в этоу версию Mattermost вошли несколько security updates, поэтому мы настоятельно рекомендуем обновиться на нее.

Прочие изменения

Этот релиз включает в себя и многие другие улучшения, включая различные security fixes. Полный список изменений доступен в Changelog.

Upgrade-барометр

Обновление до GitLab 8.10 потребует 15-30 минут даунтайма. В процессе обновления будут переименованы несколько колонок в базе данных, и для корректного обновления данных будет произведено несколько миграций. Чтобы не повредить ваши данные в процессе миграции, инстанс GitLab будет остановлен на время обновления.

Обновление конфигурации Nginx

Умолчательня конфигурация Nginx для GitLab теперь перезаписывает HTTP-заголовки ‘Host’ и ‘X-Forwarded-Host’. Это добавляет дополнительный уровень защиты от header injection attacks. Если вы ставили GitLab из исходников, то вам нужно будет обновить конфигурацию Nginx. Если вы ставили GitLab с помощью Omnibus, обновление конфигурации произойдет автоматически (если только вы не переопределили параметры ‘Host’ и ‘X-Forwarded-Host’ в файле gitlab.rb).

Git Hooks переименованы в Push Rules, а также устаревание Git Hooks API

То, что раньше называлось Git Hooks, теперь называется Push Rules. Кроме того, Git Hooks API теперь помечен как устаревшее (deprecated). Этот API будет полностью выкинут в GitLab 9.0, поэтому мы рекомендуем вам как можно скорее перейти на Push Rules.

Подробнее о Push Rules

Умолчательное поведение при обновлении

Внимание Информация в этом разделе релевантна в случае, если вы обновляетесь на GitLab 8.2 c предыдущей версии. Если это не так, то прочитайте разделы «Upgrade-барометр» для всех промежуточных версий между вашей текущей и 8.2.

Если вы обновляетесь с версии GitLab, меньшей, чем 8.0 и при этом у вас включен CI, вам нужно сначала обновиться до 8.0.

По умолчанию в процессе обновления все пакеты Omnibus будут остановлены, потом будут прогнаны все их миграции, и только потом они будут запущены снова. Это поведение не зависит от «размера» обновления. Изменить это повоедение можно, создав файл /etc/gitlab/skip-auto-migrations.

Установка

Если вы устанавливаете GitLab с «нуля», прочитайте соответствующий раздел: https://about.gitlab.com/installation/

Обновление

Инструкции по обновлению: https://about.gitlab.com/update/

Enterprise Edition

GitLab Enterprise Edition включает в себя дополнительные функции типа поддержки LDAP-групп, подтверждения (approvals) мерж-реквестов, блокировку файлов и многое другое. Подробную информацию можно посмотреть в описании GitLab EE.

GitLab EE доступен только по подписке, подробности и цены можно посмотреть вот тут.

Не хватает времени на установку и настройку нового инструмента? В стоимость подписки входят услуги по установке и обновлению GitLab на ваших серверах.

P.S. Еcли пропустили, то вот вам ссылка на перевод поста про релиз 8.9