01.10.2019 08:18
nAbdullin 0 3600 Источник


Релиз GitLab 12.3 этого месяца особенно интересен после содержательной недели, на которой мы провели первую конференцию пользователей GitLab в Бруклине, штат Нью-Йорк, и объявили о завершении этапа финансирования серии E: собрали 268 млн долларов. На эти деньги мы сможем значительно улучшить все наши предложения для DevOps, включая мониторинг, безопасность и планирование.


Брандмауэр для веб-приложений


Современные веб-приложения подвергаются новым рискам отовсюду, включая каждого подключенного клиента, который отправляет трафик. Брандмауэр для веб-приложений (Web Application Firewall, WAF) обеспечивает мониторинг и правила для защиты приложений в рабочей среде. В GitLab 12.3 мы представляем первую версию брандмауэра для веб-приложений, встроенного в платформу GitLab SDLC. Он будет заниматься мониторингом и отчетностью по вопросам безопасности для кластеров Kubernetes. В дальнейших релизах мы расширим возможности WAF, чтобы можно было блокировать вредоносный трафик, создавать правила бандмауэра и управлять ими и получать информацию на ранних этапах разработки, чтобы принять меры и сократить риски.


Productivity Analytics — первый выпуск


Командам, которые отвечают за поставку ПО, всегда нужна правильная информация и аналитика, чтобы повышать продуктивность и эффективность. Слишком часто незаметные узкие места и помехи заставляют их ждать и тратить время вместо того, чтобы заниматься новыми функциями. Начиная с релиза 12.3 мы предлагаем новые функции аналитики, чтобы команды и руководители лучше разбирались в продуктивности и эффективности групп и проектов. Productivity Analytics поможет командам и их руководителям найти лучшие методы повышения продуктивности. Изначально фокусируясь на времени, которое нужно для слияния мердж-реквестов, GitLab позволит подробно изучить данные и узнать, что и как можно улучшить. Во многих организациях руководители занимаются несколькими проектами, и рабочее пространство аналитики на уровне группы предоставляет сведения о продуктивности и производительности в нескольких проектах. Эти две фичи — первые в целом ряду обновлений, направленных на предоставление информации и аналитики, чтобы повысить эффективность.


Улучшенное соблюдение требований


Соблюдение политик и процедур доставляет разработчикам немало проблем. Многим пользователям GitLab проще обеспечить соблюдение, когда разработчики вместе работают в одном приложении. В релизе GitLab 12.3 представлено несколько функций, которые упрощают действия по снижению рисков, связанных с соблюдением требований. Правила утверждения мердж-реквестов позволяют предотвратить слияние кода, который вводит неподдерживаемые лицензии. Требование утверждения от владельца кода для каждой ветки помогает защитить ветки, ведь владелец кода должен одобрить все изменения.


И это еще не все!


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


Самый ценный сотрудник этого месяца (MVP) — Седрик Табин (Cedric Tabin)
Стараниями Седрика в GitLab 12.3 появилось новое ключевое слово для задания CI, которое разрешает прерываемые сборки. Он больше 9 месяцев работал над этой фичей и сотрудничал с нашими командами проверки, чтобы включить ее в выпуск.

Больше спасибо, Седрик, за твой неоценимый труд!

Главные фичи GitLab 12.3


Брандмауэр для веб-приложений для Kubernetes Ingress


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


GitLab теперь добавляет плагин modsecurity брандмауэра для веб-приложений (WAF) в кластер, когда вы устанавливаете приложение Ingress в кластере Kubernetes.


WAF определяет, содержит ли входящий трафик HTTP или HTTPS вредоносный код, например внедрение SQL, межсайтовый скриптинг или трояны. В WAF уже есть эффективные правила, OWASP ModSecurity Core Rules (CRS), которые определяют разные типы атак без дополнительной настройки.


В документации описывается, как просмотреть журналы WAF и узнать, какому вредоносному трафику подвержено ваше приложение в рабочей среде.



Productivity Analytics


PREMIUM, ULTIMATE, SILVER, GOLD


Сейчас источников данных и аналитики относительно мало, а эти сведения нужны руководителям, чтобы понимать продуктивность команды, проекта и группы. Как однажды сказал Питер Друкер: «Что можно измерить, можно улучшить». Руководствуясь этим принципом, мы выпускаем первую версию Productivity Analytics, чтобы помочь руководителям разобраться в типовых схемах и найти лучшие методы повысить общую производительность. Этот релиз сосредоточен на том, сколько времени занимает слияние мердж-реквеста в зависимости от размера. Пользователи могут использовать существующие фильтры и изучать подробные ведения вплоть до конкретного автора или ярлыка в группе в указанный диапазон дат. В следующих версиях Productivity Analytics мы будем добавлять дополнительные данные, чтобы можно было находить зависимости, увеличивающие время активной разработки или ожидания.


В этом первом релизе Productivity Analytics мы не стали собирать данные за прошлые периоды для новых метрик, чтобы этот фоновый процесс не помешал переходу с 12.2 на 12.3. Вы можете следить за задачей, где мы работаем над этим.



Глобальное представление для сред и развертываний кластера на уровне группы


PREMIUM, ULTIMATE, SILVER, GOLD


Операторам удобно настраивать кластер на уровне группы, чтобы предоставить разработчикам платформу разработки приложения. Масштабировать ресурсы кластера бывает непросто. Для этого требуется глобальный взгляд на использование ресурсов. Новый раздел Environments (Среды) на странице кластера содержит обзор всех проектов, которые используют кластер Kubernetes, включая подготовленные среды и развертывания и число Pod’ов в каждой среде.



Утверждение мердж-реквестов, чтобы предотвратить слияние запрещенных лицензий


ULTIMATE, GOLD


Если у вас строгие ограничения по лицензиям, можно настроить License Compliance, чтобы запретить слияние, когда в мердж-реквесте присутствует запрещенная лицензия. Так вы предотвратите появление лицензий, которые явным образом запрещены. Сейчас можно настроить утверждающих для группы License-Check в параметрах проекта и требовать проверку в соответствии с инструкциями, описанными в документации.



Другие улучшения в GitLab 12.3


Рабочее пространство аналитики


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


Инженеры и специалисты по продуктам могут входить в разные группы и проекты GitLab, но аналитика обычно разрабатывается на уровне проекта. Поэтому мы создали рабочее пространство, где пользователи могут собирать сведения из разных групп, подгрупп и проектов. Рабочее пространство аналитики упрощает анализ и управление метриками команды для участников и руководителей. Рабочее пространство будет доступно на уровне Core. Но в некоторых случаях определенные фичи будут доступны для Enterprise Edition. По мере развития рабочего пространства аналитики мы гарантируем, что существующий функционал аналитики на уровне проекта будет доступен пользователям Community Edition при переходе в новое рабочее пространство. В GitLab 12.3 мы выпускаем первую версию Productivity Analytics на уровне группы и проекта и Cycle Analytics на уровне группы. В следующих релизах можно будет выбирать разные группы и подгруппы и перенос всех функций аналитики для экземпляра. Мы будем рады услышать ваше мнение о стратегии для аналитики и управления потоком создания ценности.



Уведомления для Design Management


PREMIUM, ULTIMATE, SILVER, GOLD


В GitLab 12.2 мы выпустили первую версию Design Management. Для непрерывного развития необходимо, чтобы пользователи получали уведомления об этих действиях. Беседы в дизайнах теперь будут создавать задачи для упомянутых пользователей и отправлять уведомления в соответствии с их настройками. Это гарантирует, что они не пропустят важные отзывы и смогут принять меры. В следующем релизе мы добавим эти беседы на главную вкладку обсуждений для удобства.



API для правил утверждения мердж-реквестов


STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD


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


В GitLab 12.3 поддержка правил утверждения добавлена в API для проектов и мердж-реквестов.


Сочетания клавиш для следующего и предыдущего неразрешенного обсуждения


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


Проверка, обсуждение и разрешение фидбэка лежит в основе ревью кода на GitLab. С кнопкой Jump to next unresolved discussion (Перейти к следующему неразрешенному обсуждению) можно легко переходить от обсуждения к обсуждению.
В GitLab 12.3 новые сочетания клавиш “n” и “p” позволяют переходить к next (следующему) и previous (предыдущему) неразрешенному обсуждению в мердж-реквестах, чтобы просматривать изменения было еще удобнее.



API, требующее утверждение мердж-реквеста от владельца кода по ветке


PREMIUM, ULTIMATE, SILVER, GOLD


Утверждение мердж-реквестов ограничивает отправку кода в защищенные ветки, и это позволяет повысить качество кода и реализовать меры контроля за соблюдением требований. Но не все мердж-реквесты предназначены для стабильных веток и не все стабильные ветки требуют одинакового контроля.


В GitLab 12.3 можно требовать утверждения от владельца кода для некоторых веток (через API), чтобы предотвратить отправку изменений в файлы напрямую или слияние изменений без утверждения владельца кода.


Примечание. Эта фича доступна только через API в GitLab 12.3. В GitLab 12.4 она будет доступна в параметрах защищенной ветки. Следите за новостями в задаче 13251.


Гибкое ключевое слово “rules” для контроля поведения пайплайнов


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


Правила only/except в пайплайнах могут подразумевать разные неявные действия, и чем больше вы их добавляете, тем сложнее понять, будет ли определенное задание выполняться в разных ситуациях. Мы вводим новый синтаксис rules:, который серьезно упростит реализацию и понимание сложных правил. Этот синтаксис необязательный и может существовать в одном пайплайне, но не в одних заданиях, как текущий подход only/except.


only/except: external_pull_requests для внешних репозиториев


CORE, STARTER, PREMIUM, ULTIMATE, SILVER, GOLD


В GitLab CI можно работать с внешними репозиториями, чтобы использовать их для контроля версий, а GitLab — для CI/CD. До этого момента CI_PIPELINE_SOURCE всегда показывал push, потому что был основан на зеркале pull, а не на внешнем репозитории или вебхуке. Поэтому GitLab некорректно поддерживал only/except: merge_requests. В релизе 12.3 мы устранили это ограничение.


Удаление образов контейнеров из CI/CD


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


GitLab Container Registry позволяет пользователям собирать и отправлять образы и теги в проект с помощью GitLab CI/CD. Изменения в Container Registry вносит служебный аккаунт CI Registry User, который вызывается из .gitlab-ci.yml предопределенной переменной среды CI_REGISTRY_USER. Раньше служебный аккаунт мог отправлять новые теги в реестр, но ему не хватало разрешений, чтобы удалять эти теги. Это мешало удалению образов, относящихся к веткам, что приводило к дополнительным расходам на хранение и сложной навигации по интерфейсу реестра, ведь там было очень много лишних тегов.


В версии 12.3 мы расширили разрешения CI_REGISTRY_USER и позволили ему снимать теги образов, чтобы можно было удалять теги, относящиеся к ветке, в рамках обычного рабочего процесса CI/CD и использовать GitLab CI/CD для автоматизации скриптов очистки. Эта задача входит в большой эпик для снижения затрат на Container Registry благодаря улучшенному управлению хранением



Проверка доменов при выполнении полных активных сканов DAST


ULTIMATE, GOLD


Теперь вы можете гарантировать, что DAST выполняет только активные сканы доменов, специально настроенных для сканирования DAST.


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


В пассивных сканах DAST ничего не изменилось. Они и так никому не мешали.


Анализатор SAST Spotbugs обновлен для Java 11


ULTIMATE, GOLD


Анализатор SAST SpotBugs обновлен и теперь может сканировать код на Java 11, если настроить переменную среды SAST_JAVA_VERSION в проекте.


Кнопка Run Pipeline в пайплайнах для мердж-реквестов


PREMIUM, ULTIMATE, SILVER, GOLD


Пайплайны для мердж-реквестов недавно получили новый способ запускать пайплайн в контексте мердж-реквеста, но для этого можно было использовать только push. В этом релизе мы добавили кнопку, которая запускает новый пайплайн, и перезапускать неудавшиеся пайплайны теперь гораздо проще.


Определяемые пользователем переменные CI для docker build с Auto DevOps


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


Переменные CI позволяют настраивать выполнение процессов для сборки приложения в пайплайне CI. Начиная с GitLab 12.3 определяемые пользователем переменные могут быть доступны на этапе docker build в Auto DevOps. Данные предоставляются в виде нового значения build secret.


Выведите одну или несколько переменных с помощью переменной AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES, и она будет доступна для использования в docker build.


Knative для кластеров на уровне групп и экземпляров


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


Кластеры на уровне групп и экземпляров теперь поддерживают установку Knative — платформы на базе Kubernetes для развертывания бессерверных нагрузок и управления ими. Благодаря этому несколько проектов смогут использовать функции GitLab Serverless на одном кластере.


Линейные диаграммы для панелей с метриками


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


Часто пользователи хотят выбирать тип диаграммы в зависимости от метрики (например, линейная диаграмма для ЦП, диаграмма с областями для пространства на диске). Для этого мы добавили линейные диаграммы, чтобы усовершенствовать панель мониторинга.



Быстрые действия для добавления и удаления встреч Zoom в задачах


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


В экстренных ситуациях очень важна синхронная совместная работа. Мы оптимизируем процесс начала конференции и привлечения всех нужных специалистов, встроив эту функцию прямо в задачу с помощью Zoom.


Когда пользователь начинает встречу Zoom, он может прикрепить ее к задаче с помощью быстрого действия, введя URL-адрес встречи (например, /zoom https://gitlab.zoom.us/s/123456). В верхней части задачи появится кнопка с прямым доступом к конференц-вызову. Когда инцидент будет решен, встречу Zoom можно будет удалить командой /remove_zoom.


Эта общедоступная фича на GitLab.com, а в самоуправляемых экземплярах нужно использовать переключатель. Если вы хотите использовать эту фичу в самоуправляемом экземпляре GitLab, операторы могут включить переключатель функции issue_zoom_integration. В релизе GitLab 12.4 в следующем месяце мы планируем удалить переключатель функции и сделать интеграцию задач с Zoom общедоступной для всех пользователей самоуправляемых экземпляров.



Geo показывает задержку для вторичных узлов при операции push через Git HTTP


PREMIUM, ULTIMATE


Получение больших объемов данных может занимать много времени, если пользователь находится далеко. Репликация репозиториев с Geo ускоряет процесс клонирования и получения больших репозиториев, поскольку создает вторичные узлы только для чтения рядом с удаленным пользователем. Вторичные узлы отстают от первичного, поэтому GitLab теперь показывает примерную задержку репликации при использовании git push по HTTP. Пользователи получают больше сведений при использовании узла Geo, могут заметить увеличение задержки и сообщить о нем системным администраторам.


Из-за ограничений протокола это сообщение недоступно при использовании git pull.


Отключение двухфакторной аутентификации для некоторых провайдеров OAuth


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


Если организация использует обязательную двухфакторную аутентификацию и поставщика удостоверений, который тоже использует 2FA, пользователи могут быть недовольны двойной аутентификацией. Благодаря вкладу сообщества теперь можно отключить 2FA для некоторых провайдеров OAuth в GitLab. Так организациям, которые используют поставщиков с 2FA, будет гораздо удобнее входить на GitLab.


Спасибо за вклад, dodocat!


Ограничение IP-адреса поддерживает несколько подсетей


ULTIMATE, GOLD


В рамках развития функции ограничения действий группы по IP-адресу GitLab 12.3 представляет возможность указывать несколько подсетей IP. Это очень удобно для географически распределенных организаций: вместо того, чтобы указывать один диапазон, которому предоставляется слишком много разрешений, большие организации теперь могут ограничивать входящий трафик в зависимости от конкретных потребностей.


GitLab Runner 12.3


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


Сегодня мы выпустили GitLab Runner 12.3! GitLab Runner — это проект с открытым исходным кодом,
который используется для запуска заданий CI/CD и отправки результатов обратно в GitLab.


Изменения:



Полный список изменений можно найти в журнале изменений GitLab Runner: CHANGELOG.


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


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


Мы продолжаем улучшать производительность GitLab с каждым выпуском для экземпляров GitLab любого размера.


Некоторые улучшения в GitLab 12.3:



Статус и число обсуждений в Design Management


PREMIUM, ULTIMATE, SILVER, GOLD


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



Сжатие объявлений ссылок Git по HTTP


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


При получении изменений в репозитории Git сервер Git выдает список всех веток и тегов в репозитории. Это так называемое объявление ссылок, которое может весить много мегабайт, если проект большой.


В GitLab 12.3 при получении по HTTP объявление ссылок будет сжато для поддерживаемых клиентов, чтобы сократить объем передаваемых данных и ускорить операции получения.


В обычный будний день GitLab.com обрабатывает около 850 ГБ объявлений ссылок по HTTP. После включения сжатия ссылок этот объем сократился примерно на 70%.



Логи аудита для событий Git Push (бета)


STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD


Историю Git можно переписать, чтобы изменить коммиты, авторов и временные метки и оставить будущим разработчикам чистую и понятую историю. А вот для аудита это проблема.


В GitLab 12.3 события Git push, которые отправляют коммиты, переписывают историю или еще как-нибудь меняют репозиторий, можно добавить в лог аудита. Логи аудита для событий push отключены по умолчанию, чтобы не вредить производительности в экземплярах GitLab из-за высокого трафика записи Git.


В следующем релизе логи аудита для событий Git push будут включены по умолчанию. Следите за новостями в задаче 7865.


Более умные варианты коммитов в Web IDE по умолчанию


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


Раньше в Web IDE по умолчанию был выбран коммит в текущую ветку. Но в этом случае пользователи с разрешениями могли случайно отправить изменения в мастер или другие защищенные ветки. Теперь при внесении изменений в Web IDE варианты коммита по умолчанию не позволяют отправить изменения не в ту ветку. Более умные варианты коммита предотвращают случайную отправку в мастер и защищенные ветки для пользователей с правами на запись. Если у пользователя нет права на запись, предоставляется информация о том, почему варианты недоступны. Кроме того, новые варианты коммитов поддерживают коммиты в ветки не по умолчанию с существующим мердж-реквестом или без.



Разное время ожиданий для заданий в пайплайнах CI/CD


CORE, STARTER, PREMIUM, ULTIMATE


У разных заданий разные характеристики выполнения, поэтому время ожидания тоже может отличаться. Время ожидания можно настроить, указав ключевое слово timeout: в задании в .gitlab-ci.yml и число, которое будет означать, сколько минут нужно ждать, прежде чем произойдет сбой задания.


Спасибо за вклад, Михал Сивек (Michal Siwek)!


Ключевое слово interruptible указывает, можно ли безопасно отменить задание


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


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


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


Из-за бага в Runner некоторые исполняющие программы не останавливают запущенные задания после отмены. Мы планируем исправить это в 12.4.

Проверка статуса для триггеров пайплайнов


PREMIUM, ULTIMATE, SILVER, GOLD


Недавно мы улучшили способ, которым пайплайны в разных проектах запускают друг друга, но одного не хватало — запускающий пайплайн должен ждать или подтвердить успешное завершение следующего пайплайна. Можно было сделать это через опрос API, но в этом релизе мы представили стратегии depend и wait, которые решают эту задачу автоматически. Если выбрать depend, предыдущий пайплайн будет ждать, чтобы этот пайплайн завершился, и проверит его успех, прежде чем закончить задание запуска. Если выбрать wait, пайплайн будет ждать завершения, но продолжит заниматься своими делами даже в случае сбоя.


Конечная точка API для вывода тегов/образов Docker группы


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


С помощью GitLab Container Registry можно собирать и отправлять теги/образы Docker в проекты из командной строки, CI/CD или API. Но до выпуска GitLab 12.3 мы не предоставляли сведения о тегах и образах на уровне группы, хотя пользователи часто просят об этом.


Мы добавили две конечные точки API, которые будут показывать, какие образы и теги существуют на уровне группы. Это первый этап улучшения видимости и поиска в Container Registry. Затем мы используем API, чтобы создать браузер на уровне группы в пользовательском интерфейсе Container Registry.


Сканирование SAST без Docker-in-Docker


ULTIMATE, GOLD


Сканы SAST можно по желанию выполнять без Docker-in-Docker.


То есть можно настроить сканирование SAST, чтобы ему не требовались повышенные привилегии.


Редактирование причин игнорирования уязвимости


ULTIMATE, GOLD


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


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



Более удобная начальная настройка Pages


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


Чтобы работать с Pages было удобнее, мы добавили баннер, который уведомляет пользователей о приблизительном времени начальной настройки. Мы понимаем, как это раздражает, когда поздравительное сообщение появляется, а страница недоступна. Баннер помогает понять, чего ожидать.



Отображение кластера Kubernetes, используемого для развертывания


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


На странице сведений о задании теперь отображается имя кластера Kubernetes, который использовался для конкретного развертывания. Владельцы и мейнтейнеры проекта видят ссылку с именем кластера, которая ведет на страницу сведений о кластере.



JupyterHub для кластеров Kubernetes на уровне группы


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


Кластеры на уровне группы теперь поддерживают установку JupyterHub — многопользовательского сервиса для легкого запуска записных книжек и создания инструкций для операторов. Это расширяет доступность JupyterHub для кластеров на уровне проекта и группы.


Слэш-команда закрывает задачу в Slack


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


Решение современных ИТ-инцидентов не обходится без чатов. Этот инструмент должен быть тесно интегрирован с системами, которыми вы управляете, и инструментами, где вы исправляете ситуацию. Контекст и переключение между инструментами желательно свести к минимуму, когда вы работаете над восстановлением служб и оповещением сторонних заинтересованных лиц.


В выпуске 12.3 мы добавили дополнительную слэш-команду в набор команд в нашем продукте ChatOps на основе Slack. Теперь задачи можно закрывать в Slack, не открывая другие инструменты, — просто найдите задачу и закройте ее вручную. Задачу можно закрыть прямо там, где вы работаете.



Geo нативно поддерживает репликацию Docker Registry


PREMIUM, ULTIMATE


Geo нативно поддерживает репликацию Docker Registry между первичным и вторичным узлами Geo. Теперь пользователи Geo могут использовать Docker Registry на ближайшем вторичном узле. Этот подход не учитывает хранилище и может использоваться для хранилища объектов, например S3, или локального хранилища.


При использовании распределенного хранилища объектов (например S3) для Docker Registry первичный и вторичный узлы Geo могут использовать одинаковый тип хранилища. Этот подход не использует нативную репликацию Geo.


Действия через API включены в ограничение IP-адресов для группы


ULTIMATE, GOLD


В GitLab 12.0 представлено ограничение действий группы по IP-адресу. Мы развили эту фичу и включили в нее действия через API. Теперь входящие запросы будут отклонены, если не соответствуют ограничению группы. Это решает важную проблему для предприятий со строгими требованиями и расширенным подходом к контролю доступа, так как здесь учитываются действия в пользовательском интерфейсе и через API.


Системные хуки для обновления участников проекта и группы


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD
Системные хуки дают широкие возможности для автоматизации, запуская запросы в результате разных событий на GitLab. Благодаря вкладу сообщества изменения участников проекта и группы теперь поддерживаются в системных хуках. Это отличное дополнение для тех, кому нужен новый уровень надзора и автоматизации для изменения участников.


Спасибо за вклад, Брэндон Уильямс (Brandon Williams)!


Подписание электронной почты с S/MIME


CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD


Уведомления по электронной почте от GitLab теперь можно подписывать с S/MIME для дополнительной безопасности на уровне экземпляра.


Спасибо за вклад, Siemens, @bufferoverflow и @dlouzan!


Улучшения Omnibus


CORE, STARTER, PREMIUM, ULTIMATE



Устаревшие фичи


Пользователи с настроенным вручную .gitlab-ci.yml, использующие функции безопасности, должны ознакомиться с устаревшими фичами в GitLab 12.3


Если вы вручную настроили файл конфигурации .gitlab-ci.yml, чтобы использовать переменные параметров DEP_SCAN_DISABLE_REMOTE_CHECKS или DS_DISABLE_REMOTE_CHECKS, удалите их — они больше не поддерживаются.


Если вы используете готовые шаблоны, мы будем поддерживать актуальность вашей конфигурации с учетом изменений переменных и аргументов.
Об этом было объявлено в посте о релизе GitLab 12.0.


Дата удаления: GitLab 12.3


gitlab-monitor переименован в gitlab-exporter.


Чтобы избежать путаницы с набором фич GitLab Monitor, gitlab-monitor переименован в gitlab-exporter. gitlab-exporter — это веб-экспортер Prometheus, который предоставляет администраторам сведения об экземпляре GitLab, а фичи GitLab Monitor позволяют мониторить приложения, созданные с помощью GitLab. Если вы используете Omnibus, обновите файл gitlab.rb.


Дата удаления: 22 сентября 2019 г.


Общедоступные проекты и подгруппы в закрытых группах тоже считаются закрытыми.


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


Чтобы предотвратить ошибки в существующих общедоступных проектах и подгруппах, все общедоступные проекты и подгруппы в закрытых группах будут изменены с общедоступных на закрытые в GitLab 12.5.


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


Дата удаления: 22 ноября 2019 г.

Комментарии (0)