GitLab 11.10

GitLab 11.10 с пайплайнами на табло управления, пайплайнами для объединённых результатов и предложениями по нескольким строкам в мердж-реквестах.

Удобные данные о работоспособности пайплайнов в различных проектах

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

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

Запуск пайплайнов для объединённых результатов

Со временем исходные и целевые ветки разнесены, и может произойти ситуация, когда они работают отдельно, но не работают вместе. Теперь можно запустить пайплайны для объединённых результатов до мерджа. Так вы быстро выявите ошибки, которые проявятся только при частом перемещении изменений между ветками, и, следовательно, сможете быстрее исправить ошибки пайплайна и более эффективно использовать GitLab Runner.

Дальнейшая оптимизация совместной работы

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

Спасибо за ваши отзывы и предложения!

И это ещё не всё...

В этом выпуске столько потрясающих функций, например, ярлыки в определённой области, более тщательная очистка реестра контейнеров, компонуемый Auto DevOps и възможност покупка дополнительных минут CI Runner. Ниже подробности о каждой из них.

Самый ценный сотрудник этого месяца (MVP) — Такуя Ногути

В этом месяце самым ценным сотрудником стал Такуя Ногути (Takuya Noguchi). Такуя отлично поработал во славу GitLab: поправях бъгове, завършвах недовършената работа в бекенда и фронтенда и подобрявах потребителския интерфейс. Благодаря!

Основни функции на GitLab 11.10

Процеси на таблото за управление

PREMIUM, ULTIMATE, SILVER, GOLD

На таблото за управление в GitLab се показват информация за проектите в целия екземпляр на GitLab. Добавяте отделни проекти един по един и можете да избирате кой проект ви интересува.
В това издание добавихме информация за статуса на процесите на таблото за управление. Сега разработчиците виждат работоспособността на процесите във всички нужни проекти – в един интерфейс.

Процеси за обединени резултати

PREMIUM, ULTIMATE, SILVER, GOLD

Обикновено с времето изходната клонка се отклонява от целевата, ако не прехвърляте постоянно промени между тях. В резултат, процесите на изходната и целевата клонка са „зелени“ и няма конфликти при обединение, но при обединяване настъпва грешка поради несъвместимост на промените.

Когато процесът за обединение автоматично създава нова връзка, която съдържа обединения резултат от обединението на изходната и целевата клонка, можем да стартираме процес по тази връзка и да гарантираме, че общият резултат ще работи.

Ако използвате процеси за обединение (в какъвто и да е капацитет) и използвате частни GitLab изпълнители версия 11.8 или по-стара, те трябва да бъдат актуализирани, за да не възникне проблем. gitlab-ee#11122. Това не влияе на потребителите на публичните GitLab изпълнители.

Предлагане на промени в няколко реда

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

При съвместна работа по обединения често забелязвате проблеми и предлагате решения. От версия GitLab 11.6 поддържаме предлагане на промени за един ред.

В версия 11.10 в коментарите на диф-а на обединение можете да предлагате промени за няколко реда, а след това всеки потребител с права за запис в изходната клонка може да ги приеме с едно натискане. Благодарение на новата функция можете да избегнете копирането, както в предишните версии.

Етикети в една област

PREMIUM, ULTIMATE, SILVER, GOLD

С етикетите в една област екипите могат да прилагат взаимно изключващи се етикети (в една и съща област) за задача, обединение или епизод в сценарии с персонализирани полета или персонализирани състояния на работния поток. Те се настройват с помощта на специален синтаксис с двоеточие в заглавието на етикета.

Да предположим, че имате персонализирано поле в задачите, за да проследите операционната система на платформата, към която се насочват вашите функции. Всяка задача трябва да бъде свързана само с една платформа. Можете да създавате етикети platform::iOS, platform::Android, platform::Linux и други при необходимост. Ако приложите такъв етикет към задача, автоматично ще се премахне друг съществуващ етикет, който започва с platform::.

Да предположим, че имате етикети workflow::development, workflow::review и workflow::deployed, обозначаващи състоянието на работния процес в екипа ви. Ако задачата вече има етикет workflow::development, а разработчик иска да премести задачата в стадий workflow::review, просто прилага нов етикет, а старият (workflow::development) автоматично се премахва. Това поведение вече съществува, когато премествате задачи между списъци с етикети на дъската със задачи, която представя работния процес на вашия екип. Сега членовете на екипа, които не работят с дъската със задачи директно, могат да променят състоянието на работния процес в самите задачи.

По-подробно почистване на регистъра на контейнерите

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

При обичайна употреба на регистъра на контейнерите с CI пайплайни, изпращате няколко отделни промени в един етикет. Поради начина на разпределение на Docker, поведението по подразбиране е да съхранява всички промени в системата, но в крайна сметка те заемат много памет. Ако използвате параметъра -m с registry-garbage-collect, можете бързо да изтриете всички предишни промени и да освободите ценна място.

Закупуване на допълнителни минути за CI Runner

BRONZE, SILVER, GOLD

Потребителите с платени планове на GitLab.com (Gold, Silver, Bronze) вече могат да закупят допълнителни минути за CI Runner. По-рано трябваше да се вписват в квотата, предвидена от плана. С това подобрение можете предварително да закупите минути извън квотата, за да избегнете прекъсвания в работата поради спиране на пайплайни.

Сега 1000 минути струват 8 долара и можете да ги закупите без ограничение. Допълнителните минути ще започнат да се изразходват, когато изразходите цялата месечна квота, а остатъкът от допълнителните минути се прехвърля на следващия месец. В бъдещото издание искаме да добавим тази функция и в безплатните планове.

Компонован Auto DevOps

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

С Auto DevOps екипите преминават към съвременни практики DevOps почти без усилия. Започвайки от GitLab 11.10, всяка задача в Auto DevOps се предлага като независим шаблон. Потребителите могат да използват функцията includes в GitLab CI, за да включват отделни стадии на Auto DevOps и в същото време да използват своя персонализиран файл gitlab-ci.yml. По този начин можете да включите само необходимите задачи и да се възползвате от предимствата на актуализациите в upstream.

Автоматично управление на членовете на екипа в GitLab.com чрез SCIM

SILVER, GOLD

По-рано управлението на членството в групи в GitLab.com трябваше да се извършва ръчно. Сега можете да използвате SAML SSO и да управлявате членството чрез SCIM, за да създавате, изтривате и актуализирате потребители в GitLab.com.

Това е особено полезно за компании с голям брой потребители и централизирани удостоверители. Сега можете да имате единен източник на истина, например Azure Active Directory, и потребителите ще се създават и изтриват автоматично чрез удостоверителя, а не ръчно.

Вход в GitLab.com чрез SAML удостоверител

SILVER, GOLD

По-рано при използване на SAML SSO за група, потребителят трябваше да влиза с идентификационни данни на GitLab и удостоверителя. Сега можете да влизате директно през SSO като потребител на GitLab, свързан с настроената група.

Потребителите няма да трябва да въвеждат данните си два пъти, така че на компаниите им е по-удобно да използват SAML SSO за GitLab.com.

Други подобрения в GitLab 11.10

Схема на подепики

ULTIMATE, GOLD

В предишната версия добавихме подепики (епики на епиците), за да ви е по-удобно да управлявате структурата на разпределение на задачите. Подепиките се показват на страницата на родителския епик.

В тази версия на страницата на родителския епик се показва схемата на подепиките, така че екипите да виждат хронологията на подепиките и могат да управляват времевите зависимости.

Изскачащи екрани на мердж-реквестите

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

В тази версия представяме информативни екрани, които се появяват при задържане на курсора над линка на мердж-реквеста. По-рано показвахме само заглавието на мердж-реквеста, а сега и статуса на мердж-реквеста, статуса на CI-пайплайна и кратък URL.

В бъдещи версии планираме да добавим повече важни подробности, например, отговорни лица и контролни точки, а също така ще въведем изскачащи екрани за задачи.

Филтриране на мердж-реквестите по целеви клонове

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

Рабочите процеси на Git за освобождаването или доставянето на софтуер често са свързани с няколко дългосрочни клонове — за внасяне на корекции в предишни версии (например, stable-11-9) или преход от контрол на качеството към продукция (например, integration), но не е толкова лесно да се намерят мердж-заявки за тези клонове сред многото отворени мердж-заявки.

Списъкът с мердж-заявки за проекти и групи вече може да се филтрира по целевия клон на мердж-заявката, за да е по-лесно да се намери необходимото.

Благодаря, Хируюки Сато (Hiroyuki Sato)!

Изпращане и мердж при успешен пайплайн

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

Ако използваме метода на разработка, основан на клонове, трябва да избягваме дълготрайни клони в полза на малки времеви клони с един собственик. Малки промени често се изпращат директно в целевия клон, но в същото време рискуваме да нарушим компилацията.

В това издание GitLab поддържа нови настройки за изпращане в Git, за автоматично отваряне на мердж-заявки, задаване на целевия клон и осигуряване на мердж при успешен пайплайн от командния ред по време на изпращане в клона.

Подобрена интеграция с външни панели за мониторинг

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

GitLab може да се свързва с множество сървъри Prometheus (на ниво среда, проект и група (очаква се)), но наличието на множество крайни точки може да усложни системата или да не се поддържа от стандартните панели за мониторинг. В това издание екипите могат да използват едно API на Prometheus, което значително опростява интеграцията с такива услуги като Grafana.

Сортиране на страниците в Wiki по дата на създаване

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

В Wiki проекта екипите могат да споделят документация и друга важна информация наред с изходния код и задачите. В това издание списъкът на страниците в Wiki може да се сортира по дата на създаване и заглавие, за да се намери бързо наскоро създаденото съдържание.

Наблюдение на ресурсите, заявени от клъстера

ULTIMATE, GOLD

GitLab помага да се следи клъстерът Kubernetes за разработваните и работещите приложения. Започвайки с това издание, следете заявените от клъстера ресурси на процесора и паметта, за да забележите потенциални проблеми, преди да станат проблеми.

Преглед на метриките на балансировщика на натоварването на панела за мониторинг Grafana

CORE, STARTER, PREMIUM, ULTIMATE

Много важно да следите за работоспособността на инстанцията GitLab. По-рано предоставяхме панели за мониторинг по подразбиране чрез вградена инстанция Grafana. Започвайки от тази версия, включихме допълнителни панели за мониторинг на балансировачите на натоварването NGINX.

SAST за Elixir

ULTIMATE, GOLD

Продължаваме да разширяваме поддръжката на езици и да задълбочаваме проверките за сигурност. В тази версия включихме проверки за сигурност за проекти на Elixir и проекти, изградени на платформата Phoenix.

Няколко заявки в един график

PREMIUM, ULTIMATE, SILVER, GOLD

В GitLab можете да създавате графики, за да визуализирате събираните метрики. Често, например, когато трябва да видите максимална или средна стойност на метриката, искате да изведете няколко стойности на един график. Започвайки от тази версия, има такава възможност.

Резултати от DAST на панела за сигурност на групата

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

Добавихме резултати от динамично тестване на сигурността на приложенията (Dynamic Application Security Testing, DAST) на панела за сигурност на групата в добавка към SAST, сканирането на контейнери и сканирането на зависимости.

Добавяне на метаданни в отчета за сканиране на контейнери

ULTIMATE, GOLD

В тази версия в отчета за сканиране на контейнери има повече метаданни — добавихме засегнат компонент (функция Clair) в съществуващите метаданни: приоритет, идентификатор (с линк към mitre.org) и засегнато ниво (например, debian:8).

Добавяне на тип отчет по метрики в сливането на заявки

PREMIUM, ULTIMATE, SILVER, GOLD

GitLab вече предоставя няколко типа отчети, които могат да бъдат включвани директно в сливането на заявки: от отчети за качество на кода и модулно тестване в етапа на проверка до SAST и DAST в етапа на защита.

И макар че това са важни отчети, основна информация, подходяща за различни сценарии, също е необходима. В GitLab 11.10 предоставяме отчети по метрики директно в сливането на заявки, което очаква прост двойка ключ-стойност. Така потребителите проследяват промените във времето, включително потребителски метрики, и промените в метриките за конкретна заявка за сливане. Използването на памет, тестване на специализирани натоварвания и статуси на работоспособност могат да бъдат преобразувани в прости метрики, които могат да се преглеждат директно в сливането на заявки заедно с други вградени отчети.

Поддръжка на мултимодулни Maven проекти за сканиране на зависимости

ULTIMATE, GOLD

В тази версия мултимодулните Maven проекти поддържат сканиране на GitLab зависимости. По-рано, ако подмодулът имаше зависимост от друг подмодул на същото ниво, той не можеше да разреши зареждане от централното Maven хранилище. Сега мултимодулен Maven проект се създава с два модула и зависимост между тях. Зависимостта между модули на едно ниво вече е достъпна в локалното Maven хранилище, за да може изграждането да продължи.

Потребителите могат да променят пътя за клониране в CI

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

По подразбиране GitLab Runner клонира проекта в уникален вложен път в $CI_BUILDS_DIR. Но за някои проекти, например Golang, кодът трябва да бъде клониран в конкретна директория, за да може да бъде построен.

В GitLab 11.10 въведохме променлива GIT_CLONE_PATH, с която можете да зададете конкретен път, където GitLab Runner клонира проекта преди изпълнението на задачата.

Проста маскировка на защитени променливи в логовете

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

GitLab предлага няколко начина да защитите и да ограничите обхвата на променливите в GitLab CI/CD. Но променливите все пак могат да попаднат в логовете на сборките по намерение или случайно.

GitLab приема много сериозно управлението на риска и одита и продължава да добавя функции за спазване на изискванията. В GitLab 11.10 въведохме възможността да се маскират определени типове променливи в логовете на задачите, добавяйки ниво на защита срещу случайно попадане на съдържанието на тези променливи в логовете. Освен това GitLab автоматично маскира много вградени променливи на токени.

Включване и изключване на Auto DevOps на ниво група

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

С Auto DevOps в проекта GitLab.com можете без усилия да започнете със съвременните DevOps работни процеси — от изграждането до доставката.

Започвайки от GitLab 11.10, можете да включвате и изключвате Auto DevOps за всички проекти в една група.

Оптимизирана и подобрена страница за лицензи

STARTER, PREMIUM, ULTIMATE

За по-лесно и удобно управление на лицензионните ключове, променихме дизайна на страницата с лицензите в администраторския панел и подчертахме най-важните елементи.

Актуализация на селектора на етикети за Kubernetes деплойменти

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

На панелите за деплойменти се показват информация за всички Kubernetes деплойменти.

В тази версия променихме начина на съпоставяне на етикетите с деплойментите. Сега са налични съвпадения по app.example.com/app и app.example.com/env или app. Това ще помогне за избягване на конфликти при филтриране и рискове от неправилни разгръщания, свързани с проекта.

Освен това, в версия GitLab 12.0 ние ще премахнем етикета app от селектора за разгръщания на Kubernetes, и съвпадането ще бъде възможно само по app.example.com/app и app.example.com/env.

Динамичното създаване на ресурси в Kubernetes

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

Интеграцията на Kubernetes в GitLab позволява използването на функцията RBAC с помощта на акаунт на услуга и отделено пространство с име за всеки проект на GitLab. Започвайки от това издание, за максимална ефективност, тези ресурси ще се създават само когато са необходими за разгръщане.

При разгръщането на Kubernetes GitLab CI ще създава тези ресурси преди разгръщането.

Групови ранери за клъстери на ниво група

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

Клъстерите на ниво група вече поддържат инсталирането на GitLab Runner. Kubernetes ранери на ниво група се показват за дъщерни проекти като групови ранери, обозначени с етикети cluster и kubernetes.

Брояч на извикванията за функции Knative

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

Функции, разгръщани с GitLab Serverless, сега показват броя на получените извиквания за отделна функция. За целта е необходимо да се инсталира Prometheus в клъстера, където е инсталиран Knative.

Контрол на параметрите git clean за джобовете на GitLab CI/CD

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

По подразбиране GitLab Runner изпълнява git clean в процеса на извеждане на кода по време на изпълнението на джоб в GitLab CI/CD. Започвайки от GitLab 11.10, потребителите могат да контролират параметрите, предадени на командата git clean. Това е удобно за екипи с отделни ранери, а също и за екипи, които събират проекти от големи монорепозитории. Сега те могат да управляват процеса на извеждане преди изпълнението на скриптовете. Новата променлива GIT_CLEAN_FLAGS по подразбиране има стойност -ffdx и приема всички възможни параметри на командата [git clean](https://git-scm.com/docs/git-clean).

Външна авторизация в Core

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

Защитените среди могат да изискват допълнителен външен ресурс за авторизация за достъп до проекта. Добавихме поддръжка за допълнително ниво на контрол за достъп в 10.6 и получихме много искания да отворим тази функционалност в Core. Радваме се да представим външна авторизация и допълнително ниво на сигурност за инстанции на Core, тъй като тази функция е необходима на отделни участници.

Възможност за създаване на проекти в групи в Core

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

Ролята Developer може да създава проекти в групи още от версия 10.5, а сега това е възможно и в Core. Създаването на проекти е ключова възможност за продуктивна работа в GitLab, и благодарение на включването на тази функция в Core, участниците в инстанцията вече по-лесно могат да се захванат с нещо ново.

GitLab Runner 11.10

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

Днес пуснахме GitLab Runner 11.10! GitLab Runner е проект с отворен код, който се използва за изпълнение на CI/CD задачи и изпращане на резултатите обратно в GitLab.

Най-интересните промени:

• Параметър за указание на пътя за клониране.
• Подобрена поддръжка на git clean.
• Възможност за деактивиране на трасировката за отстраняване на грешки.
• Използване на отложено разширение на променливата за проверка на грешки в Windows Cmd.
• Поправка на цветния изход в Windows.

Пълният списък на промените може да бъде намерен в регистъра на промените на GitLab Runner: CHANGELOG.

Поправка на връщаното project_id в API за търсене на blob в Elasticsearch

STARTER, PREMIUM, ULTIMATE

Поправихме грешка в API за търсене на blob в Elasticsearch, който неправилно връщаше 0 за project_id. Необходимо е да се направи повторно индексиране на Elasticsearch, за да се получат правилните стойности project_id след инсталирането на тази версия на GitLab.

Подобрения в Omnibus

CORE, STARTER, PREMIUM, ULTIMATE

Внесохме следните подобрения в Omnibus в GitLab 11.10:

• GitLab 11.10 включва Mattermost 5.9.0, алтернатива на Slack с отворен код, в последната версия, която включва нов каталог за интеграции за лесно прехвърляне на данни от Hipchat и много други. Тази версия включва обновления за сигурност, и препоръчваме да се актуализирате.
• Ние интегрирахме Grafana с Omnibus, и сега започването на мониторинг на инстанцията на GitLab е много просто.
• Добавихме поддръжка за изтриване на стари образи на контейнери от Docker хранилището.
• Актуализирахме ca-certs до 2019-01-23.

Подобрения в производителността

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

Продължаваме да подобряваме производителността на GitLab с всяка версия за инстанции на GitLab с всякакъв размер. Някои подобрения в GitLab 11.10:

• Автозапълването на потребителите сега се извършва по-бързо.
• SQL заявките за извеждане на задачи на проекта при търсене са оптимизирани.
• Резултатите от търсенето в Elasticsearch вече не включват Gitaly.
• GraphQL заявките вече имат лимит на сложността.
• Инструментализацията за дифовете е деактивирана, за да се повиши производителността на мердж-реквестите при активно включен Prometheus.
• Подобрена производителност при импортиране на пул-реквести от GitHub.
• Търсене на комити в кеша по име на връзка.
• Подобрена производителност на дифовете на мердж-реквестите — сега blob диф файловете се кешират.

Подобрение на диаграмите на GitLab

CORE, STARTER, PREMIUM, ULTIMATE

Внесли следните подобрения в диаграмите на GitLab:

• Добавена поддръжка на Elasticsearch.

Устарели функции

GitLab Geo ще осигури хеширано хранилище в GitLab 12.0

GitLab Geo е необходим хеширано хранилище за смекчаване на конкуренцията на вторичните узли. Това беше отбелязано в gitlab-ce#40970.

В GitLab 11.5 добавихме това изискване в документацията на Geo: gitlab-ee#8053.

В GitLab 11.6 sudo gitlab-rake gitlab:geo:check проверява, дали хешираното хранилище е активирано и дали всички проекти се прехвърлят. Виж. gitlab-ee#8289. Ако използвате Geo, моля, стартирайте тази проверка и мигрирайте възможно най-скоро.

В GitLab 11.8 постоянно деактивирано предупреждение gitlab-ee!8433 ще се показва на страницата Административен район › Geo › Узли, ако гореспоменатите проверки не са разрешени.

В GitLab 12.0 Geo ще използва изискванията за хеширано хранилище. Виж. gitlab-ee#8690.

Дата на премахване: 22 юни 2019 г.

Поддръжка на Ubuntu 14.04

GitLab 11.10 ще бъде последното издание с поддръжка на Ubuntu 14.04.

Canonical обяви прекратяване на стандартната поддръжка на Ubuntu 14.04 от април 2019 г.. Препоръчваме на потребителите да преминат на поддържана версия LTS: Ubuntu 16.04 или Ubuntu 18.04.

Дата на премахване: 22 май 2019 г.

Ограничаване на максималния брой пайплайни, създадени от едно пускане

По-рано GitLab създаваше пайплайни за HEAD всяко клонче в пускането. Това е удобно за разработчиците, които пускат множество промени едновременно (например, в клон за нова функция и в клон develop).

Но при пускане на голямо хранилище, където има много активни клонове (например за преместване, отразяване или разклоняване), не е необходимо да се създава пайплайн за всеки клон. Започвайки от GitLab 11.10, създаваме максимум 4 пайплайна при пускане.

Дата на премахване: 22 май 2019 г.

Устарели пътища на legacy кода на GitLab Runner

Започвайки от GitLab 11.9, GitLab Runner използва нов метод за клониране/извикване на хранилището. В момента GitLab Runner ще използва стария метод, ако новият не е поддържан. Повече информация вижте в тази задача.

В GitLab 11.0 променихме вида на конфигурацията на сървъра за метрики за GitLab Runner. metrics_server ще бъде премахнат в полза на listen_address в GitLab 12.0. Повече информация вижте в тази задача.

В версия 11.3 GitLab Runner започна да поддържа няколко кэш-провайдера; което доведе до нови настройки за конкретна конфигурация на S3. В документацията, предоставена е таблица с промени и инструкции за преминаване към новата конфигурация. Повече информация вижте в тази задача.

Тези пътища няма да са достъпни в GitLab 12.0. Като потребител, не е нужно да променяте нищо, просто се уверете, че инстанцията на GitLab работи с версия 11.9+ при актуализиране до GitLab Runner 12.0.

Дата на премахване: 22 юни 2019 г.

Устарял параметър за функцията на входната точка за GitLab Runner

В 11.4 GitLab Runner беше представен параметър за функция FF_K8S_USE_ENTRYPOINT_OVER_COMMAND за поправяне на проблеми като #2338 и #3536.

В GitLab 12.0 ще преминем към правилно поведение, сякаш параметърът на функцията е деактивиран. Повече информация вижте в тази задача.

Дата на премахване: 22 юни 2019 г.

Устаряла поддръжка на Linux дистрибуции, достигнали EOL, за GitLab Runner

Някои дистрибуции на Linux, на които може да бъде инсталиран GitLab Runner, са достигнали края на жизнения си цикъл.

В GitLab 12.0 GitLab Runner повече няма да разпространява пакети в тези дистрибуции на Linux. Пълният списък на дистрибуциите, които повече не се поддържат, може да бъде намерен в нашия документацията. Благодаря на Хавиер Ардон (Javier Jardón) за приноса му!

Дата на премахване: 22 юни 2019 г.

Премахване на стари команди на GitLab Runner Helper

В рамките на усилията за поддръжка Windows Docker executor беше необходимо да се откажем от някои стари команди, които се използват за helper image.

В GitLab 12.0 GitLab Runner стартира с нови команди. Това засяга само потребители, които презаписват helper image. Повече информация вижте в тази задача.

Дата на премахване: 22 юни 2019 г.

Премахване на наследствения механизъм git clean от GitLab Runner

В GitLab Runner 11.10 предоставихме възможност да конфигурирате как Runner изпълнява командата git clean. Освен това, новата стратегия за почистване премахва използването на git reset и поставя командата git clean след стъпката на изтегляне.

Тъй като това изменение на поведението може да повлияе на някои потребители, подготвихме параметър FF_USE_LEGACY_GIT_CLEAN_STRATEGY. Ако зададете стойност истинно, той ще възвърне наследствената стратегия за почистване. Повече информация за използването на параметрите на функциите в GitLab Runner може да намерите в документацията.

В GitLab Runner 12.0 ще премахнем поддръжката на наследствената стратегия за почистване и възможността за нейното възстановяване чрез параметъра на функцията. Повече информация вижте в тази задача.

Дата на премахване: 22 юни 2019 г.

Раздел System Info в администраторския панел

GitLab предоставя информация за вашата инстанция на GitLab в admin/system_info, но тази информация може да е неточна.

Ние ще премахнем този раздел администраторския панел в GitLab 12.0 и препоръчваме да използвате други възможности за мониторинг.

Дата на премахване: 22 юни 2019 г.

История на промените

Търсете всички тези промени в историята на промените:

• GitLab Community Edition
• GitLab Enterprise Edition
• GitLab Runner

Инсталиране

Ако настройвате нова инсталация на GitLab, посетете страницата за изтегляне на GitLab.

Актуализация

Погледнете в страницата за актуализации.

Плановете за абонамент на GitLab

GitLab е наличен в два варианта: самоуправляем и облачен SaaS.

Самоуправляем: локално или на предпочитана облачна платформа.

• Ядро: за малки екипи, лични проекти или безсрочна пробна версия на GitLab.
• Starter: за екипи, работещи в един офис по множество проекти, които се нуждаят от професионална поддръжка.
• Премиум: за разпределени екипи, нуждаещи се от разширени функции, висока наличност и 24/7 поддръжка.
• Ултимейт: за предприятия, които изискват надеждна стратегия и изпълнение с подобрена безопасност и спазване на регулации.

Облачен SaaS — GitLab.com: хоства, управлява и администрира GitLab по безплатни и платени абонаменти за индивидуални разработчици и екипи.

• Безплатен: неограничени частни репозитории и неограничен брой участници в проектите. Закритите проекти получават достъп до функции от ниво Безплатен, а отворените проекти имат достъп до функции от ниво Gold.
• Bronze: за екипи, които имат нужда от достъп до разширени функции на работния процес.
• Silver: за екипи, които се нуждаят от по-надеждни DevOps възможности, спазване на регулации и бърза поддръжка.
• Gold: подходящо за множество CI/CD задачи. Всички отворени проекти могат безплатно да използват функции от Gold независимо от плана.

Източник: habr.com