Бързо откриване на секретни течове
Изглежда малка грешка случайно да се предадат идентификационни данни към споделено хранилище. Последствията обаче могат да бъдат сериозни. След като нападателят получи вашата парола или API ключ, той ще поеме акаунта ви, ще ви блокира и ще използва измамно вашите пари. Освен това е възможен ефект на доминото: достъпът до един акаунт отваря достъп до други. Залозите са високи, така че е изключително важно да научите за изтеклите тайни възможно най-скоро.
В тази версия представяме опцията в рамките на нашата SAST функционалност. Всеки комит се сканира в CI/CD задание за тайни. Има тайна - и разработчикът получава предупреждение в заявката за сливане. Той отменя изтеклите идентификационни данни на място и създава нови.
Осигуряване на правилно управление на промените
Тъй като тя расте и става по-сложна, става по-трудно да се поддържа последователност между различните части на организацията. Колкото повече са потребителите на приложението и колкото по-висок е доходът, толкова по-сериозни са последиците от сливането на неправилен или опасен код. За много организации осигуряването на правилен процес на преглед преди сливане на код е трудно изискване, тъй като рисковете са толкова високи.
Благодарение на GitLab 11.9 има повече контрол и по-ефективна структура . Преди това, за да получите разрешение, беше достатъчно да посочите индивид или група (всеки член на която може да даде разрешение). Сега можете да добавите някои правила, така че заявката за сливане да изисква разрешение от конкретни лица или дори от няколко членове на конкретна група. В допълнение, функцията Code Owners е интегрирана в правилата за разрешение, което улеснява идентифицирането на лицето, което е издало разрешението.
Това позволява на организациите да прилагат сложни процеси за разрешаване, като същевременно поддържат простотата на едно приложение на GitLab, където проблемите, кодът, тръбопроводите и данните за мониторинг са видими и достъпни за вземане на решения и ускоряване на процеса на разрешаване.
ChatOps вече е с отворен код
GitLab ChatOps е мощен инструмент за автоматизация, който ви позволява да изпълнявате всяка CI/CD задача и да правите заявки за състоянието й директно от приложения за чат като Slack и Mattermost. , ChatOps беше част от абонамента GitLab Ultimate. Базиран и , понякога местим функции на ниво надолу и никога нагоре.
В случая с ChatOps разбрахме, че тази функционалност може да бъде полезна за всички и че участието на общността може да бъде от полза за самата функция.
В GitLab 11.9 ние , и като такъв вече е свободно достъпен за използване в самоуправляваното GitLab Core и на GitLab.com и е отворен за общността.
И още много!
В тази версия има толкова много страхотни функции: напр. , и - че нямаме търпение да разкажем за тях!
Най-ценният служител) от този месец се признава от Марсел Амиро ()
Марсел постоянно ни помага да подобряваме документацията на GitLab. Той за подобряване на качеството и използваемостта на нашите документи. Domo arigato [много ви благодаря (яп.) - прибл. прев.] Марсел, ние искрено го оценяваме!
Основни функции, добавени във версия GitLab 11.9
Откриване на тайни и идентификационни данни в хранилище
(КРАЕН, ЗЛАТЕН)
Разработчиците понякога по невнимание предават тайни и идентификационни данни на отдалечени хранилища. Ако други хора имат достъп до този източник или ако проектът е публичен, тогава чувствителната информация е изложена и може да бъде използвана от нападателите за достъп до ресурси като среди за разполагане.
GitLab 11.9 има нов тест, наречен „Secret Detection“. Той сканира съдържанието на хранилището за API ключове и друга информация, която не трябва да е там. GitLab показва резултатите в отчета SAST в изпълнимия модул за заявка за сливане, отчети за конвейер и табла за сигурност.
Ако вече сте активирали SAST за вашето приложение, тогава не е необходимо да правите нищо, просто се възползвайте от тази нова функция. Той също е включен в конфигурацията по подразбиране.
Правила за разрешаване на заявки за сливане
(PREMIUM, ULTIMATE, SILVER, GOLD)
Прегледите на кода са неразделна част от всеки успешен проект, но не винаги е ясно кой трябва да преглежда промените. Често е желателно да има рецензенти от различни екипи: екипът за разработка, екипът за потребителско изживяване, производственият екип.
Правилата за разрешения ви позволяват да подобрите процеса на взаимодействие между лицата, участващи в прегледите на кода: дефинирани са кръгът от упълномощени одобряващи и минималният брой разрешения. Правилата за разрешение се показват в изпълнимия модул за заявка за сливане, така че следващият рецензент да може бързо да бъде назначен.
В GitLab 11.8 правилата за разрешения бяха деактивирани по подразбиране. От GitLab 11.9 те са налични по подразбиране. В GitLab 11.3 въведохме опцията за определяне на членове на екипа, отговорни за отделните кодове в рамките на проект. Функцията за собственици на кодове е интегрирана в правилата за разрешения, така че винаги можете бързо да намерите точните хора, които да прегледат промените.
Преместване на ChatOps към Core
(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, така че можете да видите какво е променено и кога. Имаше инцидент и трябва да видите какво се е променило наскоро? Или просто трябва да проверите как са променени функционалните параметри като част от одита? Сега това е много лесно да се направи.
Коригиране на уязвимостите на искането за сливане
(КРАЕН, ЗЛАТЕН)
За да коригирате бързо уязвимостите в кода, процесът трябва да е прост. Важно е да се опростят корекциите за сигурност, позволявайки на разработчиците да се съсредоточат върху преките си отговорности. В GitLab 11.7 ние , но трябваше да бъде изтеглен, приложен локално и след това избутан в отдалечено хранилище.
В GitLab 11.9 този процес е автоматизиран. Коригирайте уязвимостите, без да напускате уеб интерфейса на GitLab. Заявката за сливане се създава директно от прозореца с информация за уязвимостта и този нов клон вече ще съдържа корекцията. След като проверите дали проблемът е разрешен, добавете корекцията към оригиналния клон, ако тръбопроводът е наред.
Показване на резултатите от сканирането на контейнера в таблото за сигурност на групата
(КРАЕН, ЗЛАТЕН)
Таблото за управление на екипната сигурност позволява на професионалистите да се съсредоточат върху това, което е най-важно за тяхната работа, като предоставя ясен и подробен преглед на всички възможни уязвимости, които биха могли да засегнат приложенията. Ето защо е важно таблото за управление да има цялата информация, от която се нуждаете, на едно място и да позволява на потребителите да изследват данните в детайли, преди да коригират уязвимостите.
В GitLab 11.9 резултатите от сканиране на контейнери са добавени към таблото за управление в допълнение към вече наличните резултати от сканиране на SAST и зависимости. Сега целият преглед е на едно място, независимо от източника на проблема.
CI/CD шаблони за работни места по сигурността
(КРАЕН, ЗЛАТЕН)
Функциите за сигурност на GitLab се развиват много бързо и изискват постоянни актуализации, за да поддържате вашия код ефективен и защитен. Промяната на определението за работа е трудна, когато управлявате множество проекти. Освен това разбираме, че никой не иска да поеме риска да използва най-новата версия на GitLab, без да се увери, че е напълно съвместима с текущия екземпляр на GitLab.
Поради тази причина въведохме нов механизъм за дефиниране на работа в GitLab 11.7 с помощта на .
Започвайки с GitLab 11.9, ние ще предлагаме вградени шаблони за всички задачи по сигурността: напр. sast и dependency_scanning, - съвместим със съответната версия на GitLab.
Включете ги директно във вашата конфигурация и те ще бъдат актуализирани със системата всеки път, когато надстроите до нова версия на GitLab. Конфигурациите на тръбопровода не се променят.
Новият начин за дефиниране на задания за сигурност е официален и не поддържа други предишни дефиниции на задания или кодови фрагменти. Дефиницията трябва да се актуализира възможно най-скоро, за да се използва новата ключова дума
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.
Изискване на разрешение за заявки за сливане от собствениците на кодове
(PREMIUM, ULTIMATE, SILVER, GOLD)
Не винаги е очевидно кой одобрява искането за сливане.
GitLab вече поддържа изискване да одобрите заявка за сливане, в зависимост от това кои файлове модифицира заявката, с . Собствениците на кодове се присвояват с помощта на файл, наречен CODEOWNERS, форматът е подобен на gitattributes.
Добавена е поддръжка за автоматично присвояване на собственици на кодове като лица, отговорни за одобряване на заявка за сливане .
Преместване на файлове в уеб 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)
Наскоро въведохме функция, която позволява на потребителите да филтрират емисията за действие по проблеми, заявки за сливане или епоси, което ви позволява да се съсредоточите само върху коментари или системни бележки. Тази настройка се запазва за всеки потребител в системата и може да се случи потребителят да не разбере, че когато преглежда задача няколко дни по-късно, вижда филтриран канал. Струва му се, че е невъзможно да остави коментар.
Подобрихме това взаимодействие. Сега потребителите могат бързо да превключат към режим, който им позволява да оставят коментари, без да превъртат обратно в горната част на емисията. Това се отнася за проблеми, заявки за сливане и епоси.
Пренаредете детските епоси
(КРАЕН, ЗЛАТЕН)
Наскоро пуснахме , което ви позволява да използвате епоси на епоси (в допълнение към дъщерните задачи на епоси).
Вече е възможно да пренаредите дъщерни епоси на епоси с просто плъзгане и пускане, какъвто е случаят с дъщерните задачи. Екипите могат да използват реда, за да отразят приоритета или да определят реда, в който работата трябва да бъде завършена.
Персонализирани системни съобщения в горен и долен колонтитул за уеб и имейл
(CORE, STARTER, PREMIUM, ULTIMATE)
По-рано добавихме функция, която позволява персонализирани съобщения в горен и долен колонтитул да се показват на всяка страница в GitLab. Тя беше топло посрещната и екипите я използват, за да споделят важна информация, като например системни съобщения, свързани с техния екземпляр на GitLab.
Ние сме развълнувани да предоставим тази функция на Core, така че още повече хора да могат да я използват. В допълнение, ние позволяваме на потребителите по избор да показват едни и същи съобщения във всички имейли, изпратени чрез GitLab, за съгласуваност с различна точка на взаимодействие на потребителя с GitLab.
Филтрирайте по поверителни задачи
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Confidential Issues е полезен инструмент за екипи да водят лични дискусии по чувствителни теми в рамките на отворен проект. По-специално, те са идеални за работа върху уязвимости в сигурността. Досега управлението на поверителни задачи не беше лесно.
В GitLab 11.9 списъкът с проблеми на GitLab вече е филтриран по чувствителни или неповерителни проблеми. Това се отнася и за търсене на задачи с помощта на API.
Благодаря за приноса на Робърт Шилинг ()!
Редактиране на Knative домейн след внедряване
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Указването на персонализиран домейн при инсталиране на Knative ви позволява да обслужвате различни безсървърни приложения/функции от уникална крайна точка.
Сега интегрирането на Kubernetes в GitLab ви позволява да промените/актуализирате персонализиран домейн след разполагане на Knative в клъстер на Kubernetes.
Проверка на формата на Kubernetes CA сертификат
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Когато добавя съществуващ клъстер на Kubernetes, GitLab сега проверява дали въведеният CA сертификат е във валиден PEM формат. Това елиминира потенциални грешки при интегрирането на Kubernetes.
Разширяване на помощната програма за сравнение на заявки за сливане до целия файл
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Когато преглеждате промени в заявка за сливане, вече е възможно да разширите помощната програма за разлики за всеки файл, за да покажете целия файл за повече контекст и да оставите коментари върху непроменени редове.
Изпълнение на специфични задачи при заявки за сливане само когато определени файлове са променени
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab 11.6 добави възможност за дефиниране за конвейерни задания, така че потребителите да могат да изпълняват само конкретни задачи, когато създават заявка за сливане.
Сега разширяваме тази функционалност: добавена е логика за свързване и потребителите могат да изпълняват само конкретни задания за заявки за сливане и само когато определени файлове са модифицирани.
Благодаря за приноса Hiroyuki Sato ()!
Автоматично наблюдение на GitLab с Grafana
(CORE, STARTER, PREMIUM, ULTIMATE)
Grafana вече е включена в нашия пакет Omnibus, което улеснява разбирането как работи вашето копие.
Персонализирайте grafana['enable'] = true в gitlab.rb, а Grafana ще бъде достъпен на: https://your.gitlab.instance/-/grafana. В близко бъдеще ще го направим и ние "от кутията".
Вижте първичните епоси в страничната лента на епосите
(КРАЕН, ЗЛАТЕН)
Наскоро представихме , което ви позволява да използвате епоси от епоси.
В GitLab 11.9 опростихме механизма за преглед на тази връзка. Сега се вижда не само родителската епопея на дадена епопея, но и цялото епично дърво в страничната лента вдясно. Можете да видите дали тези епоси са затворени или не и дори можете да отидете директно до тях.
Връзка към нов брой от преместен и затворен брой
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
В GitLab можете лесно да преместите проблем в друг проект, като използвате страничната лента или бързо действие. Зад кулисите съществуващата задача се затваря и се създава нова задача в целевия проект с всички копирани данни, включително системни бележки и атрибути на страничната лента. Това е страхотна функция.
Като се има предвид, че има системна бележка за преместването, потребителите, когато преглеждат затворен въпрос, са объркани: те не могат да не разберат, че проблемът е затворен поради преместване.
В тази версия ще посочим точно върху иконата в горната част на страницата със затворен проблем, че той е преместен, и ще включим вградена връзка към новия брой, така че всеки, който стигне до стария, да може бързо да премине към нова.
Youtrack интеграция
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab се интегрира с много външни системи за проследяване на проблеми, което улеснява екипите да използват GitLab за други функции, като същевременно запазват избрания от тях инструмент за управление на проблеми.
В тази версия добавихме възможност за интегриране на YouTrack от JetBrains.
Благодаря за приноса на Kotau Yauhen ()!
Преоразмеряване на файловото дърво на искането за сливане
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Когато преглеждате промените в искането за сливане, вече можете да преоразмерите файловото дърво, за да показвате дълги имена на файлове или да спестите място на по-малки екрани.
Преминете към последните ленти на задачите
(СТАРТЕР, ПРЕМИУМ, КРАЙЕН, БРОНЗ, СРЕБРО, ЗЛАТО)
Таблата за управление са много удобни и екипите създават множество табла за управление за всеки проект и екип. Наскоро добавихме лента за търсене за бързо филтриране на всички ленти, които ви интересуват.
В GitLab 11.9 също въведохме раздел Скорошен в падащия списък. По този начин можете бързо да навигирате до панелите, с които наскоро сте взаимодействали.
Възможност за разработчиците да създават защитени клонове
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Защитените разклонения предотвратяват преместването или обединяването на непрегледан код. Въпреки това, ако на никой не е позволено да премества защитени клонове, тогава никой не може да създаде нов защитен клон: например клон за освобождаване.
В GitLab 11.9 разработчиците могат да създават защитени клонове от вече защитени клонове чрез GitLab или API. Използването на Git за преместване на нов защитен клон все още е ограничено, за да се избегне случайно създаване на нови защитени клонове.
Дедупликация на Git обект за отворени разклонения (бета)
(CORE, STARTER, PREMIUM, ULTIMATE)
Разклоняването позволява на всеки да допринася за проекти с отворен код: без разрешение за запис, просто чрез копиране на хранилището в нов проект. Поддържането на пълни копия на често раздвоявани Git хранилища е неефективно. Сега с Git alternatives forks споделят общи обекти от проект нагоре по веригата в пул от обекти, за да намалят изискванията за дисково съхранение.
Пулове обекти Fork се създават само за отворени проекти, ако е свързано хеширано хранилище. Пулове обекти се активират чрез функционален параметър object_pools.
Филтриране на списъка със заявки за сливане по назначени одобряващи
(СТАРТЕР, ПРЕМИУМ, КРАЙЕН, БРОНЗ, СРЕБРО, ЗЛАТО)
Прегледите на кода са обичайна практика за всеки успешен проект, но за рецензента може да бъде трудно да следи заявките за сливане.
В GitLab 11.9 списъкът със заявки за сливане се филтрира от назначения одобряващ. По този начин можете да намерите заявки за сливане, добавени от вас като рецензент.
Благодарим на Glevin Wiechert за неговия принос ()!
Клавишни комбинации за следващ и предишен файл в заявка за сливане
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Когато преглеждате промени в заявка за сливане, можете бързо да превключвате между файлове, като използвате ]или j за да преминете към следващия файл и [ или k за да отидете на предишния файл.
Опростяване .gitlab-ci.yml за проекти без сървър
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Изграден на базата на функционалност GitLab CI шаблон без сървър gitlab-ci.yml силно опростен. Не е необходимо да правите промени в този файл, за да въведете нови функции в бъдещи версии.
Поддръжка на име на хост Ingress
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
По време на внедряването на Kubernetes Ingress контролер някои платформи се връщат към IP адрес (като GKE от Google), а други към DNS име (като EKS от AWS).
Нашата интеграция с Kubernetes вече поддържа и двата типа крайни точки за показване в секцията clusters проект.
Благодаря за приноса на Арън Уокър ()!
Ограничете достъпа за влизане в JupyterHub само до членовете на екипа/проекта
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Внедряването на JupyterHub с помощта на интеграция на GitLab с Kubernetes е чудесен начин за обслужване и използване на Jupyter Notebook в големи групи. Също така е полезно да контролирате достъпа до тях, когато прехвърляте чувствителни или лични данни.
В GitLab 11.9 възможността за влизане в екземпляри на JupyterHub, внедрени чрез Kubernetes, е ограничена до членове на проекта с достъп за разработчици (чрез група или проект).
Персонализируеми времеви диапазони за схеми на охранителни панели
(КРАЕН, ЗЛАТЕН)
Таблото за сигурност на екипа включва диаграма на уязвимостите за преглед на текущото състояние на сигурността на проектите на екипа. Това е много полезно за директорите по сигурността, за да настроят процеси и да разберат как работи екипът.
В 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.
Благодаря на Арън Уокър за приноса!
Актуализация на Code Climate до версия 0.83.0
(СТАРТЕР, ПРЕМИУМ, КРАЙЕН, БРОНЗ, СРЕБРО, ЗЛАТО)
GitLab използва за да проверите как промените влияят на състоянието на вашия код и проект.
В GitLab 11.9 актуализирахме двигателя до най-новата версия (), за да осигури предимствата на допълнителен език и поддръжка за статичен анализ за GitLab Code Quality.
Благодаря за приноса от члена на основния екип на GitLab Такуя Ногучи ()!
Мащабиране и превъртане на таблото за управление на показателите
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Когато изследвате аномалии в производителността, често е полезно да разгледате по-отблизо отделните части на конкретен показател.
С GitLab 11.9 потребителите ще могат да увеличават мащаба на отделни периоди от време в таблото за управление на показателите, да превъртат през целия период от време и лесно да се връщат към оригиналния изглед на период от време. Това ви позволява лесно и бързо да изследвате събитията, от които се нуждаете.
SAST за TypeScript
(КРАЕН, ЗЛАТЕН)
е сравнително нов език за програмиране, базиран на .
В GitLab 11.9 функцията за статично тестване на сигурността на приложението (SAST) анализира и открива уязвимостите на кода на TypeScript, като ги разкрива в изпълнимия модул за заявка за сливане, на ниво конвейер и в таблото за сигурност. Настоящото определение за работа sast не е необходимо да се променя и също така автоматично се включва в .
SAST за многомодулни проекти на Maven
(КРАЕН, ЗЛАТЕН)
Проектите на 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:
- Добавена е поддръжка за Google Cloud Memorystore.
- Настройки за работа на Cron защото се използват от множество услуги.
- Регистърът е актуализиран до версия 2.7.1.
- Добавена е нова настройка, за да направи регистъра на GitLab съвместим с версии на Docker преди 1.10. За да активирате, инсталирайте
registry.compatibility.schema1.enabled: true.
Подобряване на представянето
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Продължаваме да подобряваме производителността на GitLab с всяко издание за екземпляри на GitLab от всякакъв размер. Ето някои от подобренията в GitLab 11.9:
- .
- .
- .
- .
Омнибус подобрения
(CORE, STARTER, PREMIUM, ULTIMATE)
GitLab 11.9 носи следните Omnibus подобрения:
- GitLab 11.9 включва , , чиято последна версия включва MFA за Team Edition, подобрена производителност на изображението и др. Тази версия също включва ; препоръчва се актуализация.
- Добавена е нова настройка, за да направи регистъра на GitLab съвместим с версии на 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 за смекчаване на конкуренцията (състезание) на вторичните възли. Това беше отбелязано в .
В GitLab добавихме това изискване към Geo документацията: .
В GitLab sudo gitlab-rake gitlab: geo: check проверява дали хешираното съхранение е активирано и дали всички проекти са мигрирани. См. . Ако използвате Geo, моля, изпълнете тази проверка и мигрирайте възможно най-скоро.
В GitLab предупреждение за постоянно деактивирано ще се покаже на страницата Административна област › Географски › Възлиако горните проверки не са разрешени.
В GitLab Geo ще използва изисквания за хеширано съхранение. См. .
Дата на изтриване: 22 2019 юни
Hipchat интеграция
HipChat . Освен това във версия 11.9 .
Дата на изтриване: 22 2019 март
Поддръжка на CentOS 6 за GitLab Runner с помощта на Docker изпълнител
GitLab Runner не поддържа CentOS 6 при използване на Docker в GitLab 11.9. Това е резултат от актуализация на основната Docker библиотека, която вече не поддържа CentOS 6. Вижте повече на .
Дата на изтриване: 22 2019 март
Наследени кодови пътища на 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 юни
TLSv1.1
Започвайки с GitLab за подобряване на сигурността. Това коригира множество проблеми, включително 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 юни
Предишни дефиниции на длъжностите за сигурност
С въвеждането всички предишни дефиниции на работа са отхвърлени и ще бъдат премахнати в GitLab 12.0 или по-нова версия.
Актуализирайте дефинициите си за работа, за да използвате новия синтаксис и да се възползвате от всички нови функции за сигурност, предоставени от GitLab.
Дата на премахване: 22 юни 2019 г
Секция за системна информация в административния панел
GitLab представя информация за вашия екземпляр на GitLab в admin/system_info, но тази информация може да не е точна.
Ние административен панел в GitLab 12.0 и препоръчваме да използвате .
Дата на изтриване: 22 2019 юни
Източник: www.habr.com