Всем привет. В этот раз задержка с переводом релизного поста получилась всего 10 дней, и это радует.
Переводом в этот раз занимался chebureque, за что ему большая благодарность! Коротко: Увеличилась производительность, появилась защита веток от изменений с использованием масок, улучшили отображение диффов, добавили ручные действия в CI, массовую подписка на тикеты, улучшили поддержку Slack и добавили больше эмодзи. Сам текст перевода: Основная задача GitLab — позволить вам как можно быстрее пройти путь от идеи до готового к использованию продукта. Каждый наш релиз направлен на то, чтобы сделать этот путь еще проще, и версия 8.10 особенно преуспела в этом! GitLab 8.10 упрощает процессы ревью и мержа кода: теперь в вашем распоряжении еще более удобные диффы и дополнительные фичи для защиты веток от случайных изменений. А когда придет время развертывания готового кода, вы сможете воспользоваться функцией ручных проверок перед тем, как развернуть ваш код одним кликом. Наш июльский (MVP) — Winnie! Он очень сильно помог нам, исправляя баги и наводя порядок в нашем issue tracker-е. Чтобы обезопасить ветки от случайного удаления или изменения, их можно защищать. Этот механизм, среди прочего, позволяет разрешать или запрещать доступ к веткам на запись в зависимости от прав пользователей — например, можно не давать рядовым разработчикам пушить или мержить в 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, и теперь они показывают изменения в еще более наглядном виде.  Есл изменения затрагивают только часть строки, мы покажем вам именно ее измененную порцию (а не строку целиком):  Теперь вы можете схлапывать диффы, кликая на имя файла. Это поможет вам удобным образом просматривать изменения файл за файлом.  Большие диффы (> 10kb) будут всегда показываться схлопнутыми (но вы в любой момент можете развернуть их). Это должно здорово помочь, если вам постоянно приходится просматривать много больших изменений в большом количестве файлов Конечно же, вы уже настроили конвейер (pipeline) для Continuous Integration / Continuous Delivery? Использовать такой автоматический конвейер для развертывания на production может быть не самой лучшей идеей. Автоматическое развертывание на staging — вполне нормальная практика, но перед переносом кода в production лучше все-таки провести хотя бы несколько ручных тестов, чтобы окончательно убедиться, что всё работает нормально. Теперь вы можете задавать активируемые вручную условия для развертывания в production. Опция when: manual добавит в веб-интерфейс новое действие, которое нужно будет активировать вручную — и конвейер продолжит выполнение только после этого ручного действия. Например, ваш релиз-менеджер нажмет эту кнопку после того, как вручную удостоверится, что на staging все работает нормально. Любая задача (job) в вашем конвейере может быть помечена опцией when: manual.  Эти действия также отображаются в окружениях (environments), чтобы вам было проще переводить сборки из staging в production.  Если вы хотите пометить несколько строк в вашем markdown-файле как цитату, вам больше необязательно приписывать к каждой строке >. Теперь для этого есть многострочный синтаксис: Теперь вы можете распределить данные ваших репозиториев по нескольким точкам монтирования (mount points). Просто укажите все необходимые mount points в файле  gitlab.rb: После этого в панели администратора GitLab вы сможете указывать, под какой точкой монтирования нужно хранить каждый новый репозиторий. Теперь вы можете подписываться (и отписываться) на большое количество тикетов одновременно. Это полезно в случаях, если вы хотите с ходу нырнуть в новый проект и быть в курсе всего и сразу, или наоборот, хотите побыть в тишине от постоянных email-уведомлений.  В предыдущей версии (8.9) мы добавили индивидуальные оповещения, чтобы вы получали уведомления только об интересующих вас проектных событиях. В GitLab 8.10 вы можете управлять этими настройками для групп проектов, выставляя одинаковые настройки оповещения сразу для нескольких проектов (не забывайте, что индивидуальные настройки проекта имеют приоритет над групповыми). До версии 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. Теперь вы можете запретить пользователям, не входящим в проект или группу, подавать заявки на вступление туда. По умолчанию такие заявки разрешены. GitLab теперь может оповещать вас о разных проектных событиях через Slack — будь то комментарий к тикету, создание нового мерж-реквеста или сломавшаяся сборка. Slack service теперь позволяет вам настроить, в какой Slack-канал будет приходить сообщение о каждом событии.   
Мы обновились до версии gemojione за 2016 год, и теперь эмодзи стало еще больше.  Теперь можно вносить доменные имена в черный список, и почтовые адреса с этих доменов не смогут регистрироваться в вашем инстансе GitLab. Настройки, связанные с черным списком, находятся в панели администратора. Теперь вы можете независимо управлять протоколами доступа к Git: вы можно разрешить доступ к репозиторию только через HTTP, только через SSH или одновременно через HTTP+SSH Если в тексте  тикета, комментария или мерж-реквеста содержится ссылка на видео, то GitLab отобразит этот видеоролик прямо в тексте. Как вы знаете, CI-конвейер можно настроить таким образом, чтобы ошибки при выполнении каких-то задач (jobs) в нем не считались фатальными. При возникновении таких ошибок CI-конвейер выводит предупреждения (warnings). В GitLab 8.10 эти предупреждения будут видны вам в том мерж-реквесте, который их породил  Чтобы лучше понять, как именно клиенты используют GitLab, 8.10 EE регулярно отправляет анонимную статистическую информацию на сервера GitLab, Inc. Если идея вам не по душе, отключите эту опцию на странице "Application settings" (на этой же странице вы видно, какие данные будут отправлены на наш сервер.  От релиза к релизу GitLab становится лучше и лучше по всем параметрам — и в том числе и по  быстродействию. В этом месяце мы ускорили отображение тикетов в 2-2.5 раза и диффов на треть:   Для интересующихся — вот список значительных изменений в версии 8.10 и ссылки на соответствующие мерж-реквесты. С этого момента runner-релизы будут синхронизированы с ежемесячными основными релизами GitLab. Изменения в этом runner-релизе:: Вместе с GitLab 8.10 поставляется и Gitlab Mattermost 3.2, открытый аналог Slack. В Mattermost 3.2 были добавлены немецкая локализация, новые эмодзи, улучшенное отображение веток обсуждений (threads), полноэкранный поисковый интерфейс, интеграции с MS Exchange и XMPP, и многое другое. Кроме того, в этоу версию Mattermost вошли несколько security updates, поэтому мы настоятельно рекомендуем обновиться на нее. Этот релиз включает в себя и многие другие улучшения, включая различные security fixes. Полный список изменений доступен в Changelog. Обновление до GitLab 8.10 потребует 15-30 минут даунтайма. В процессе обновления будут переименованы несколько колонок в базе данных, и для корректного обновления данных будет произведено несколько миграций. Чтобы не повредить ваши данные в процессе миграции, инстанс GitLab будет остановлен на время обновления. Умолчательня конфигурация 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 теперь помечен как устаревшее (deprecated). Этот API будет полностью выкинут в GitLab 9.0, поэтому мы рекомендуем вам как можно скорее перейти на 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/ GitLab Enterprise Edition включает в себя дополнительные функции типа поддержки LDAP-групп, подтверждения (approvals) мерж-реквестов, блокировку файлов и многое другое. Подробную информацию можно посмотреть в описании GitLab EE. GitLab EE доступен только по подписке, подробности и цены можно посмотреть вот тут. Не хватает времени на установку и настройку нового инструмента? В стоимость подписки входят услуги по установке и обновлению GitLab на ваших серверах. P.S. Еcли пропустили, то вот вам ссылка на перевод поста про релиз 8.9 Smartprogrammer.ru