Бързо откриване на теч на тайни
Изглежда, че малка грешка — случайното предаване на удостоверителни данни в общ репозиторий. Все пак последствията могат да бъдат сериозни. След като нападателят получи вашата парола или API ключ, той ще завладее вашия акаунт, ще ви блокира и ще манипулира средствата ви. Освен това може да се получи и домино ефект: достъпът до един акаунт отваря достъпа до други. Възможностите са сериозни, затова е изключително важно да се информирате за теч на тайни възможно най-скоро.
В тази версия представяме опция в рамките на нашата SAST функционалност. Всеки комит се сканира в CI/CD задачата за наличието на тайни. Има тайна — разработчикът получава предупреждение в merge request. Той веднага анулира изтеклите удостоверителни данни и създава нови.
Осигуряване на правилно управление на промените
С нарастваща сложност става все по-трудно да се поддържа последователност между различните части на организацията. Колкото повече потребители има приложението и колкото по-високи са приходите, толкова по-сериозни са последствията от сливането на неправилен или нерегламентиран код. За много организации осигуряването на правилния процес на проверка преди сливането на кода е строго изискване, тъй като рисковете са много високи.
В GitLab 11.9 има повече контрол и по-ефективна структура — благодарение на . По-рано за получаване на разрешение беше достатъчно да се посочи отделно лице или група (всеки член от която може да предостави разрешение). Сега може да се добавят няколко правила, така че merge request-ът да изисква разрешение от конкретни лица или дори от няколко члена на конкретна група. Освен това, в правилата за разрешаване е интегрирана функцията Code Owners, която позволява лесно определяне на лицето, което е дало разрешението.
Това позволява на организациите да реализират сложни процеси на разрешаване, запазвайки в същото време простотата на единната GitLab апликация, където задачите, кодът, пайплайните и данните за мониторинг са видими и достъпни за вземане на решения и ускоряване на процеса на разрешаване.
ChatOps вече е с отворен код
GitLab ChatOps е ефективен инструмент за автоматизация, който позволява изпълняването на всяка CI/CD работа и запитване за нейния статус директно в чат приложения като Slack и Mattermost. , ChatOps беше част от абонамента GitLab Ultimate. Изхождайки от и , понякога преместим функции на по-ниско ниво и никога - на по-високо.
В случая с ChatOps осъзнахме, че тази функционалност може да е полезна за всички и че участието на общността може да е от полза за самата функция.
В GitLab 11.9 ние , и така, сега е безплатно достъпен за използване в самоуправляван GitLab Core и на GitLab.com и е отворен за общността.
И много повече!
В тази версия има толкова много страхотни функции: например, , и , — така че нямаме търпение да говорим за тях!
Най-ценният служител () на този месец е признат Марсел Амир ()
Марсел постоянно ни помагаше да подобрим документацията на GitLab. Той за повишаване на качеството и удобството при използването на нашите документи. Даймос аригато [много благодаря (яп.) — бел. прев.] Марсел, искрено го оценяваме!
Основни функции, добавени в GitLab 11.9
Откриване на секрети и идентификационни данни в репозитория
(ULTIMATE, GOLD)
Разработчиците понякога неволно предават в отдалечени репозитории секрети и идентификационни данни. Ако имат достъп до този източник, или ако проектът е отворен, конфиденциалната информация може да бъде разкрита и използвана от злонамерени лица за достъп до ресурси като среди на разгръщане.
GitLab 11.9 има нов тест - “Secret Detection”. Той сканира съдържанието на репозитория в търсене на API ключове и друга информация, която не трябва да е тук. GitLab показва резултатите в отчета SAST в джаджата за мердж реквести, в отчетите за пайплайни и на панелите за сигурност.
Ако вече сте свързали SAST за вашето приложение, не трябва да правите нищо, просто се възползвайте от предимствата на тази нова функция. Тя също е включена в конфигурацията по подразбиране.
Правила за одобрение на мердж реквести
(PREMIUM, ULTIMATE, SILVER, GOLD)
Код ревюто е неразривна част от всеки успешен проект, но не винаги е ясно, кой трябва да се заеме с рецензирането на промените. Често е желателно участие от рецензенти от различни екипи: екипа на разработчиците, екипа за взаимодействие с потребителите, производствения екип.
Правилата за разрешения позволяват усъвършенстване на процеса на взаимодействие между лицата, участващи в прегледа на кода: определя се кръгът на упълномощените одобрители и минималният брой разрешения. Правилата за разрешения се показват в джаджата за заявка за сливане, така че може бързо да назначите следващия рецензент.
В GitLab 11.8 правилата за разрешения бяха по подразбиране изключени. От версия GitLab 11.9 те са на разположение по подразбиране. В GitLab 11.3 въведохме опция за обозначаване на членовете на екипа, отговорни за отделни кодове в рамките на проекта. Функцията Собственици на код е интегрирана в правилата за разрешения, така че винаги можете бързо да намерите нужните хора, за да прегледат промените.
Преместване на ChatOps в ядрото
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Първоначално въведен в GitLab Ultimate 10.6, ChatOps премина в GitLab Core. GitLab ChatOps предлага възможност за стартиране на задачи от GitLab CI чрез Slack с помощта на функцията .
Отваряме изходния код на тази функция в съответствие с нашия . Честото използване на нея ще допринесе по-голямо участие от общността.
Аудит на параметрите на функциите
(PREMIUM, ULTIMATE, SILVER, GOLD)
Операции, като добавяне, изтриване или промяна на параметрите на функции, сега се регистрират в журнала на одита на GitLab, което ви позволява да видите какво и кога е било променено. Имало е авария и трябва да се провери какво е променено напоследък? Или просто е необходимо в рамките на одита да се провери как са били изменени параметрите на функциите? Сега е много лесно.
Отстраняване на уязвимости в мердж реквестите
(ULTIMATE, GOLD)
За бързо отстраняване на уязвимости в кода, процесът трябва да бъде прост. Важно е да се улеснят корекциите на сигурността, позволявайки на разработчиците да се фокусират върху приоритетните задължения. В GitLab 11.7 ние , но той трябваше да бъде изтеглен, приложен на локално ниво и след това промените да бъдат преместени в отдалечения репозитори.
В GitLab 11.9 този процес е автоматизиран. Отстранете уязвимостите, без да напускате уеб интерфейса на GitLab. Заявка за сливане се създава директно от прозореца с информация за уязвимостите, и тази нова клонка вече ще съдържа корекция. След като проверите дали проблемът е решен, добавете корекцията в основната клонка, ако пайплайнът е в ред.
Показване на резултатите от сканирането на контейнери на таблото за безопасност на групата
(ULTIMATE, GOLD)
Груповата панел за сигурност позволява на специалистите да се фокусират върху най-важните аспекти на работата, предоставяйки ясен и подробен преглед на всички възможни уязвимости, които могат да повлияят на приложенията. Затова е важно панелът да съдържа всяка необходима информация на едно място и да позволява на потребителите да проучат данните в детайли, преди да поправят уязвимостите.
В GitLab 11.9 резултатите от сканирането на контейнерите бяха добавени към таблото, в допълнение към вече наличните резултати от SAST и анализа на зависимостите. Сега целият преглед е на едно място, независимо от източника на проблема.
Шаблони CI/CD за security jobs
(ULTIMATE, GOLD)
Функциите за сигурност на GitLab напредват много бързо и постоянно изискват актуализации, за да поддържат ефективността и защитата на кода. Промяната на дефиницията на работата е сложна, когато управлявате множество проекти. Освен това разбираме: никой не желае да рискува, използвайки последната версия на GitLab без уверяване за нейната пълна съвместимост с текущия екземпляр на GitLab.
Точно поради тази причина представихме в GitLab 11.7 нов механизъм за дефиниране на работата с помощта на .
Започвайки от GitLab 11.9, ще предлагаме вградени шаблони за всички security jobs: например, sast и dependency_scanning, — съвместими с подходящата версия на GitLab.
Включвайте ги директно в конфигурацията си и те ще се актуализират заедно със системата при всяка актуализация до нова версия на GitLab. Конфигурациите на пайплайна при това не се променят.
Новият начин на дефиниране на security jobs е официален и не поддържа всякакви други предишни дефиниции на работата или фрагменти от код. Трябва да актуализирате определенията възможно най-скоро, за да използвате новата ключова дума
template. Поддръжката на какъвто и да било друг синтаксис може да бъде премахната в GitLab 12.0 или в други бъдещи издания.
Други подобрения в GitLab 11.9
Отговор на коментар
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
В GitLab има дискусии по теми. Досега потребителят, който пише оригиналния коментар, е трябвало да реши от самото начало дали иска обсъждане.
Ние отслабихме това ограничение. Вземете всеки коментар в GitLab (по задачи, мердж-реквести и епики) и отговорете на него, започвайки по този начин дискусия. Така екипите взаимодействат по-организирано.
Шаблони за проекти за .NET, Go, iOS и Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
За да улесним потребителите да създават нови проекти, предлагаме няколко нови шаблона за проекти:
- Начален , който включва основно приложение с CI.
- Готов шаблон, комбиниращ и GitLab CI/CD.
- , готово за начална персонализация в GitLab. Обърнете внимание, че тъй като за изграждане на iOS е необходим отделен MacOS runner, трябва да предоставите собствен сървър за изграждане, ако искате да го използвате с GitLab CI/CD.
- са настроени да работят с Netlify.
Изисквайте одобрение на мердж-реквестите от Code Owners
(PREMIUM, ULTIMATE, SILVER, GOLD)
Не винаги е очевидно кой одобрява мердж-реквест.
Сега GitLab поддържа изискването за одобрение на мердж-реквест в зависимост от файловете, които променя заявката, с помощта на . Code Owners се назначават с помощта на файл, наречен CODEOWNERS, форматът е подобен на gitattributes.
Поддръжката за автоматично назначаване на Code Owners като отговорни лица за одобряване на мердж-реквеста беше добавена в .
Преместване на файлове в Web IDE
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Сега, след като преименувате файл или каталог, можете да го преместите от Web IDE в репозитория по нов път.
Етикети по азбучен ред
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Етикетите в GitLab са изключително универсални и екипите постоянно намират нови приложения за тях. Следователно, потребителите често добавят много етикети към задача, мердж-реквест или епик.
В GitLab 11.9 ние опростихме малко използването на етикети. В задачите, мердж-реквестите и епиките етикетите, показващи се в страничната лента, са подредени по азбучен ред. Това важи и за прегледа на списъка с тези обекти.
Бързи коментари при филтриране на действия по задача
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Наскоро въведохме функция, с която потребителите филтрират лентата с действия по задачи, мердж-реквести или епики, което позволява да се съсредоточат само върху коментарите или системните бележки. Тази опция се запазва за всеки потребител в системата и понякога потребителят може да не осъзнава, че, преглеждайки задача няколко дни по-късно, вижда филтрирана лента. Изглежда му, че не може да остави коментар.
Ние подобрихме взаимодействието. Сега потребителите могат бързо да преминат в режим, който позволява оставянето на коментари, без да се налага да превъртат потока обратно нагоре. Това се отнася за задачи, merge requests и епики.
Промяна на реда на дочерните епики
(ULTIMATE, GOLD)
Наскоро пуснахме , които позволяват използването на епики на епики (в допълнение към дочерните задачи на епиките).
Сега можете да променяте реда на дочерните епики на епиките просто чрез влачене, както при дочерните задачи. Екипите могат да използват реда, за да отразяват приоритета или да определят реда на изпълнение на задачите.
Персонализирани системни съобщения в горния и долния колонтитул в интернет и електронната поща
(CORE, STARTER, PREMIUM, ULTIMATE)
По-рано добавихме функция, която позволява на персонализираните съобщения в горния и долния колонтитул да се показват на всяка страница в GitLab. Тя бе посрещната позитивно, а екипите я използват за обмен на важна информация: например, системни съобщения, свързани с техния GitLab инстанция.
С радост въвеждаме тази функция в Core, така че сега още повече хора могат да я използват. Освен това разрешаваме на потребителите по желание да показват същите съобщения в всичките електронни писма, изпращани чрез GitLab, за последователност с другата точка на взаимодействие на потребителя с GitLab.
Филтър за конфиденциални задачи
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Конфиденциалните задачи са полезен инструмент за екипите, позволяващ в рамките на отворен проект да се провеждат закрити дискусии по деликатни теми. Те са идеални за работа по уязвимости в сигурността. До сега управлението на конфиденциални задачи не беше особено лесно.
В GitLab 11.9 списъкът с задачи вече се филтрира по конфиденциални или неконфиденциални задачи. Това се отнася и за търсенето на задачи чрез API.
Благодарим за приноса на Роберт Шилинг ()!
Редактиране на домейн Knative след разгръщане
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Посочването на потребителски домейн при инсталиране на Knative позволява обслужването на различни serverless приложения/функции с уникална крайна точка.
Сега интеграцията на Kubernetes с GitLab позволява промяна/обновяване на потребителския домейн след деплой на Knative в кластер Kubernetes.
Проверка на формата на сертификата Kubernetes CA
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
При добавяне на съществуващ Kubernetes клъстер, GitLab вече проверява дали въведеният CA сертификат има допустим формат PEM. Това предотвратява потенциални грешки при интеграцията на Kubernetes.
Разширение на утилитата за сравняване на merge request-и за целия файл
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
При преглеждане на промените в merge request-а, вече е възможно разширяване на утилитата за сравняване за всеки файл, за да се покаже целият файл за повече контекст и да се оставят коментари в неизменените редове.
Изпълнение на конкретни задачи по merge request-и само при промяна на определени файлове
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
В GitLab 11.6 добавиха възможността да се определи за задачите в pipeline-ите, за да могат потребителите да изпълняват конкретни задания само при създаването на merge request.
Сега разширяваме тази функционалност: добавена е логика за свързване , и потребителите могат да изпълняват конкретни задачи само за merge request-и и само при промяна на определени файлове.
Благодарим на Hiroyuki Sato за приноса му ()!
Автоматизирано мониторинг решение за GitLab с Grafana
(CORE, STARTER, PREMIUM, ULTIMATE)
Grafana вече е част от нашия пакет Omnibus, което улеснява разбирането на функционирането на вашия екземпляр.
Настройте grafana['enable'] = true в gitlab.rb, и Grafana ще бъде достъпна на адрес: https://your.gitlab.instance/-/grafana. В най-скоро време ще въведем и панел инструментариум на GitLab Преглед на основните епики в страничната лента на епиците
Наскоро представихме
(ULTIMATE, GOLD)
, позволяващи използването на епики на епиките. В GitLab 11.9 опростихме механизма за преглед на тази взаимовръзка. Сега е видим не само родителският епик на зададения епик, но и цялото дърво на епиците в страничната лента вдясно. Видно е дали тези епики са затворени или не, и може дори да преминете директно към тях.
Връзка към нова задача от преместена и затворена задача
В GitLab е лесно да преместите задача в друг проект чрез страничната лента или бързо действие. Зад кулисите, съществуващата задача се затваря, и в целевия проект се създава нова задача с всички копирани данни, включително системни бележки и атрибути от страничната лента. Това е чудесна функция.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
С оглед на съществуващата системна бележка за преместената задача, потребителите при преглед на затворената задача се сблъскват с объркване: не могат да разберат, че задачата е затворена поради преместене.
При наличието на системна бележка за преместената задача, потребителите, когато преглеждат затворената задача, изпитват недоумение: не могат да осъзнаят, че задачата е затворена поради преместенето.
В тази версия указваме директно на значка в горната част на страницата на затворената задача, че тя е преместена, а също така включваме вградена връзка към новата задача, за да може всеки, който е попаднал на старата, бързо да премине към новата.
Интеграция на YouTrack
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab се интегрира с много външни системи за проследяване на задачи, което улеснява екипите да използват GitLab за други функции, запазвайки избрания от тях инструмент за управление на задачи.
В тази версия добавихме възможност за интеграция на YouTrack от JetBrains.
Благодарим за приноса на Котау Яухен ()!
Промяна на размера на дървото на файловете в мерж-реквеста
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
При преглед на промените в мерж-реквеста сега можете да променяте размера на дървото на файловете, за да показвате дълги имена на файлове или да спестите място на малки екрани.
Преминаване към последните панели за задачи
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Панелите за задачи са много удобни и екипите създават по няколко панела за всеки проект и група. Напоследък добавихме панел за търсене, за да филтрирате бързо всички панели, които ви интересуват.
В GitLab 11.9 също така представихме секция Recent в падащото меню. Така можете бързо да преминете към панелите, с които сте взаимодействали наскоро.
Възможност за разработчиците да създават защитени клони
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Защитените клонове не позволяват преместване или мерджване на неревюиран код. Въпреки това, ако никой не е разрешен да преместват защитени клонове, тогава никой не може да създаде нов защитен клон: например, клон на версия.
В GitLab 11.9 разработчиците могат да създават защитени клонове от вече защитени клонове чрез GitLab или API. Използването на Git за преместване на нов защитен клон все още е ограничено — за да не създават случайно нови защитени клонове.
Дедупликация на Git обекти за отворени клони (бета)
(CORE, STARTER, PREMIUM, ULTIMATE)
Клонирането позволява на всеки да участва в проекти с отворен код: без разрешение за писане, просто копирайки хранилището в нов проект. Съхраняването на пълни копия на често клонирани Git хранилища не е ефективно. Сега с помощта на Git alternatives клонирането споделя общи обекти от надредения проект в обектния пул, за да намали изискванията за дисково хранилище.
Обектните пулове за разклонения се създават само за отворени проекти, ако е свързано хеширано хранилище. Обектните пулове се активират чрез параметъра на функцията object_pools.
Филтриране на списъка с мердж реквести по назначени одобряващи лица
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Ревюто на кода е обичайна практика за успешен проект, но на рецензента може да му бъде трудно да проследи мердж реквестите.
В GitLab 11.9 списъкът с мердж реквести се филтрира по назначеното одобряващо лице. Така можете да намерите мердж реквестите, назначени на вас като рецензент.
Благодарим за приноса на Глевин Вихерт ()!
Бързи клавиши за следващия и предишния файл в мердж реквеста
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Когато разглеждате промените в мердж реквеста, можете бързо да превключвате между файловете с помощта на ]или j за преминаване към следващия файл и [ или k за преминаване към предишния файл.
Оптимизация .gitlab-ci.yml за serverless проекти
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Създаден на основата на функционалността на GitLab CI, serverless шаблон gitlab-ci.yml значително е опростен. За да се добавят нови функции в бъдещите версии, изменения в този файл не са необходими.
Поддръжка на имена на хостове Ingress
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
По време на внедряването на контролера Kubernetes Ingress, някои платформи се връщат към IP адрес (например, GKE от Google), а други - към DNS име (например, EKS от AWS).
Нашата интеграция с Kubernetes сега поддържа и двата типа крайни точки за показване в раздела clusters проектa.
Благодарим за приноса на Аарон Уокър ()!
Ограничаване на достъпа до JupyterHub само за членове на групата/проекта
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Внедряването на JupyterHub с помощта на интеграцията на GitLab с Kubernetes е отличен начин за поддържане и използване на Jupyter Notebook в големи групи. Също така е полезно да се контролира достъпът до тях при прехвърляне на конфиденциални или лични данни.
В GitLab 11.9 възможността за вход в инстанции на JupyterHub, внедрени чрез Kubernetes, е ограничена до членове на проекта с ниво на достъп “разработчик” (чрез група или проект).
Настройваеми времеви диапазони за схемата на контролния панел за сигурност
(ULTIMATE, GOLD)
Контролният панел за сигурност на групата включва схема за уязвимости за преглед на текущия статус на сигурността на проектите на групата. Това е много полезно за директорите по сигурност, за да настроят процесите и да разберат механизма на работа на екипа.
В GitLab 11.9 вече можете да изберете времеви диапазон за тази схема на уязвимости. По подразбиране е последните 90 дни, но може да зададете интервал от 60 или 30 дни в зависимост от необходимото ниво на детайлност.
Това не влияе на данните в броячите или в списъка, само на точките на данни, които се показват на схемата.
Добавяне на работа по изграждане на Auto DevOps за тагове
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Етапът на автоматичното изграждане на Auto DevOps създава сборка на вашето приложение, използвайки Dockerfile на проекта или пакета за изграждане на Heroku.
В GitLab 11.9 полученото Docker изображение, интегрирано в пайплайна на таговете, получава име, подобно на традиционните имена на образите, с помощта на комит таг вместо комит SHA.
Благодарим за приноса на Аарон Уокър (Aaron Walker)!
Актуализация на Code Climate до версия 0.83.0
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab използва за проверка на това как промените влияят на състоянието на вашия код и проект.
В GitLab 11.9 обновихме двигателя до последната версия () за да предоставим предимства от допълнителния език и поддръжка на статичен анализ за GitLab Code Quality.
Благодарим за приноса на члена на екипа на GitLab Core Такуия Ногути ()!
Мащабиране и превъртане на панела с метрики
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Когато изследвате аномалии в производителността, често е полезно да се вгледате по-внимателно в отделни части на определена метрика.
С GitLab 11.9 потребителите ще могат да мащабират отделни времеви периоди на панела с метрики, да превъртат целия времеви интервал и лесно да се връщат към вида на оригиналния времеви интервал. Това позволява лесно и бързо да се изследват нужните събития.
SAST за TypeScript
(ULTIMATE, GOLD)
— това е сравнително нов език за програмиране на базата на .
В GitLab 11.9 функцията за Статично тестване на сигурността на приложението (SAST) анализира и открива уязвимости в кода на TypeScript, показвайки ги в джаджа за свързване на заявките, на ниво пайплайн и на панела за сигурност. Текущото определение на работата sast не трябва да се променя, и то също така е автоматично включено в .
SAST за многомодулни проекти Maven
(ULTIMATE, GOLD)
Проектите Maven често са организирани така, че да обединяват в едно хранилище. Преди GitLab не можеше правилно да скенира такива проекти, и разработчиците и специалистите по сигурността не получаваха отчети за уязвимости.
GitLab 11.9 предлага καθηλωτική υποστήριξη για την λειτουργία SAST στη συγκεκριμένη αυτή διαμόρφωση έργου, επιτρέποντας τη δυνατότητα δοκιμής για ευπάθειες σε κατάσταση πηγαίου κώδικα. Χάρη στην ευελιξία των αναλυτών, η διαμόρφωση καθορίζεται αυτόματα, χωρίς να χρειάζεται να αλλάξετε κάτι για να δείτε τα αποτελέσματα σε πολυεπίπεδες εφαρμογές Maven. Όπως συνήθως, παρόμοιες βελτιώσεις είναι επίσης διαθέσιμες στο πλαίσιο .
GitLab Runner 11.9
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Σήμερα κυκλοφόρησε επίσης το GitLab Runner 11.9! Το GitLab Runner είναι ένα έργο ανοιχτού κώδικα και χρησιμοποιείται για την εκτέλεση εργασιών CI/CD και την αποστολή αποτελεσμάτων πίσω στο GitLab.
Πιο κάτω παρατίθενται κάποιες αλλαγές στο GitLab Runner 11.9:
- .
- и .
- . Αυτή είναι επίσης .
- για υποστήριξη , που θα εμφανιστούν στο GitLab 11.10.
- .
- .
- Μεταφορά αρκετών σεναρίων — συμπεριλαμβανομένου του и — στο Go.
- .
- .
- .
Пълният списък на промените може да бъде намерен в регистъра на промените на GitLab Runner: .
Βελτιώσεις στο σχέδιο του GitLab
(CORE, STARTER, PREMIUM, ULTIMATE)
Στο GitLab chart έγιναν οι παρακάτω βελτιώσεις:
- Προστέθηκε υποστήριξη για Google Cloud Memorystore.
- Οι ρυθμίσεις Cron job , καθώς χρησιμοποιούνται από πολλές υπηρεσίες.
- Ο registry αναβαθμίστηκε στην έκδοση 2.7.1.
- Προστέθηκε νέα παράμετρος που εξασφαλίζει τη συμβατότητα του GitLab registry με εκδόσεις Docker έως και 1.10. Για να την ενεργοποιήσετε, ορίστε
registry.compatibility.schema1.enabled: true.
Подобрение на производителността
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Συνεχίζουμε να βελτιώνουμε την απόδοση του GitLab με κάθε κυκλοφορία για περιπτώσεις GitLab οποιουδήποτε μεγέθους. Ορίστε κάποιες βελτιώσεις στο GitLab 11.9:
- .
- .
- .
- .
Подобрения в Omnibus
(CORE, STARTER, PREMIUM, ULTIMATE)
Στο GitLab 11.9 έγιναν οι παρακάτω βελτιώσεις Omnibus:
- GitLab 11.9 включва , , в последния релиз, който включва MFA за Team Edition, подобрена производителност на изображенията и много други. Тази версия също така включва ; препоръчва се ъпгрейд.
- Προστέθηκε νέα παράμετρος που εξασφαλίζει τη συμβατότητα του GitLab registry με εκδόσεις Docker έως και 1.10. Για να την ενεργοποιήσετε, ορίστε
registry['compatibility_schema1_enabled'] = true в gitlab.rb. - Реестърът на GitLab сега експортира метрики Prometheus и автоматично се контролира от включения в .
- Добавена е поддръжка за Google Cloud Memorystore, която изисква .
opensslъпдейтнат до версия 1.0.2r,nginx— до версия 1.14.2,python— до версия 3.4.9,jemalloc— до версия 5.1.0,docutils— до версия 0.13.1,gitlab-monitor— до версия 3.2.0.
Устарели функции
GitLab Geo ще осигури хеширано хранилище в GitLab 12.0
GitLab Geo е необходим за смекчаване на конкуренцията (race condition) на вторични възли. Това беше отбелязано в .
В GitLab добавихме това изискване в документацията на Geo: .
В GitLab sudo gitlab-rake gitlab: geo: check проверява, дали хешираното хранилище е активирано и дали всички проекти се прехвърлят. Виж. . Ако използвате Geo, моля, стартирайте тази проверка и мигрирайте възможно най-скоро.
В GitLab постоянно деактивирано предупреждение ще се показва на страницата Административна зона › Geo › Възли, ако гореспоменатите проверки не са разрешени.
В GitLab Geo ще използва изискванията за хеширано хранилище. Виж. .
Дата на премахване: 22 юни 2019 г.
Интеграция на Hipchat
Hipchat . Освен това, в версия 11.9 .
Дата на премахване: 22 март 2019 г.
Поддръжка на CentOS 6 за GitLab Runner с помощта на Docker executor
GitLab Runner не поддържа CentOS 6, когато се използва Docker в GitLab 11.9. Това е резултат от актуализация на основната библиотека Docker, която вече не поддържа CentOS 6. За повече информация вижте в .
Дата на премахване: 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 започна да поддържа , което доведе до нови настройки за . В представена е таблица с промени и инструкции за преминаване към новата конфигурация. За повече информация вижте в .
Тези пътища вече не са достъпни в GitLab 12.0. Като потребител, не трябва да променяте нищо, просто се уверете, че инстанцията на GitLab работи с версия 11.9+ при ъпгрейд към GitLab Runner 12.0.
Дата на премахване: 22 юни 2019 г.
Устарял параметър за функцията на входната точка за GitLab Runner
В 11.4 GitLab Runner беше представен параметър за функция за поправяне на проблеми като и .
В GitLab 12.0 ще преминем към правилно поведение, сякаш параметърът на функцията е деактивиран. Повече информация вижте в .
Дата на премахване: 22 юни 2019 г.
Устаряла поддръжка на Linux дистрибуции, достигнали EOL, за GitLab Runner
Някои дистрибуции на Linux, на които може да бъде инсталиран GitLab Runner, са достигнали края на жизнения си цикъл.
В GitLab 12.0 GitLab Runner повече няма да разпространява пакети в тези дистрибуции на Linux. Пълният списък на дистрибуциите, които повече не се поддържат, може да бъде намерен в нашия . Благодаря на Хавиер Ардон () за неговия !
Дата на премахване: 22 юни 2019 г.
Премахване на стари команди на GitLab Runner Helper
В рамките на усилията за поддръжка беше необходимо да се откажем от някои стари команди, които се използват за .
В GitLab 12.0 GitLab Runner се стартира с нови команди. Това касае само потребители, които пренастройват . Повече информация вижте в .
Дата на премахване: 22 юни 2019 г.
Разработчиците могат да изтриват Git тагове в GitLab 11.10
Изтриването или редактирането на бележки за версията за Git тагове в нездравословни клони исторически е било ограничено само до .
Тъй като разработчиците могат да добавят тагове, както и да променят и изтриват нездравословни клони, те трябва да имат възможност да изтриват Git тагове. В GitLab 11.10 в нашата модел на разрешения, за да подобрим работния процес и да помогнем на разработчиците да използват таговете по-добре и по-ефективно.
Ако искате да запазите това ограничение за сопровождащи и собственици, използвайте .
Дата на премахване: 22 април 2019 г.
Поддръжка на Prometheus 1.x в Omnibus GitLab
Започвайки с GitLab , вградената версия на Prometheus 1.0 е изключена от Omnibus GitLab. . Форматът на метриките обаче не е съвместим с версия 1.0. Съществуващите версии могат да се актуализират до 2.0 и, ако е необходимо, данните .
В GitLab версия Prometheus 2.0 ще се инсталира автоматично, ако актуализацията все още не е била извършена. Данните от Prometheus 1.0 ще бъдат загубени, тъй като не могат да бъдат пренесени.
Дата на премахване: 22 юни 2019 г.
TLS v1.1
Започвайки с GitLab за повишаване на сигурността. Това elimинира множество проблеми, включително Heartbleed, и прави GitLab ”извън кутията” съвместим със стандарта PCI DSS 3.1.
За незабавно изключване на TLS v1.1, задайте nginx['ssl_protocols'] = "TLSv1.2" в gitlab.rband и стартирайте gitlab-ctl reconfigure.
Дата на премахване: 22 юни 2019 г.
Шаблон OpenShift за инсталиране на GitLab
Официален — препоръчаният метод за работа на GitLab в Kubernetes, включително .
за инсталиране на GitLab е остарял и няма да бъде поддържан в .
Дата на премахване: 22 юни 2019 г.
Предишни определения за security jobs
С въвеждането на всички предишни определения за джобове остаряват и ще бъдат премахнати в GitLab 12.0 или по-късно.
Актуализирайте определенията на джобовете, за да използвате новия синтаксис и да се възползвате от всички нови функции за сигурност, предоставени от GitLab.
Дата на премахване: 22 юни 2019 г.
Раздел System Info в администраторския панел
GitLab предоставя информация за вашата инстанция на GitLab в admin/system_info, но тази информация може да е неточна.
Ние администраторския панел в GitLab 12.0 и препоръчваме да използвате .
Дата на премахване: 22 юни 2019 г.
Източник: habr.com
