# CI 변수 및 Kubernetes Agent용 HashiCorp 스토리지와 함께 GitLab 13.4가 출시되었습니다.

릴리스 13.4는 CI 변수, Kubernetes 에이전트 및 보안 센터를 위한 HashiCorp 스토리지는 물론 Starter의 전환 가능한 기능과 함께 출시되었습니다.

GitLab에서는 사용자가 선호하는 플랫폼에서 위험을 줄이고 효율성을 향상하며 전송 속도를 향상시킬 수 있는 방법에 대해 항상 생각하고 있습니다. 이번 달에는 보안 기능을 확장하고, 취약점 수를 줄이고, 효율성을 높이고, GitLab 작업을 단순화하고, 팀이 기능을 더욱 빠르게 제공하는 데 도움이 되는 유용한 새 기능을 많이 추가했습니다. 이번 릴리스의 주요 기능이 유용할 뿐만 아니라 53가지 다른 새로운 기능, 이번 릴리스에 추가되었습니다.

고급 보안 기능

우리는 매달 GitLab DevSecOps에 몇 가지 새로운 기능을 추가하려고 노력하고 있으며 이번 릴리스도 예외는 아닙니다. 이제 HashiCorp 저장소의 비밀 키를 CI/CD 작업에 사용할 수 있습니다. 조립 및 배포 프레임워크 내에서. 또한 코드 배포 책임 분리를 지원하려는 조직은 이제 Reporter 액세스 권한이 있는 사용자에게 배포자 역할 추가. 이 역할은 해당 최소 접근 권한의 원칙 코드 자체를 변경할 수 있는 액세스 권한을 제공하지 않고도 병합 요청(GitLab "병합 요청"의 러시아어 현지화)을 확인하고 보안 환경에 코드를 배포할 수 있습니다.

위험을 줄이는 또 다른 방법은 새로운 것을 사용하는 것입니다. GitLab Kubernetes 에이전트. 운영팀은 클러스터를 전체 인터넷에 노출하지 않고도 GitLab에서 Kubernetes 클러스터를 배포할 수 있습니다. 또한 새로운 Terraform 상태 파일에 대한 자동 버전 제어 지원을 도입합니다. GitLab 관리 Terraform 상태 규정 준수 및 디버깅 용이성을 지원합니다. 마지막으로 인스턴스 보안 대시보드는 GitLab 보안 센터 취약점 보고서 및 보안 설정이 있습니다.

GitLab으로 더욱 편리하고 효율적으로 업무를 수행하세요

다음을 포함하도록 글로벌 검색을 개선했습니다. 검색창에서 빠른 탐색를 사용하면 최신 티켓, 그룹, 프로젝트, 설정 및 도움말 항목으로 쉽게 이동할 수 있습니다. GitLab 페이지를 발표하게 되어 기쁘게 생각합니다. 리디렉션이 나타났습니다 사이트 내의 개별 페이지와 디렉토리를 리디렉션하여 사용자가 사이트를 보다 효율적으로 배포할 수 있도록 합니다. 그리고 배포에 대한 자세한 정보를 받고자 하는 사람들을 위해 이번 릴리스에서는 환경 도구 모음에서 지원되는 수백 개의 프로젝트 배포를 관리합니다.!

오픈 소스 기여

우리는 대표 병합 요청 차이점에 코드 적용 범위 표시내가 추가한 것 이번달 MVP 파비오 후세르. 변경된 코드의 단위 테스트 적용 범위에 대한 표시는 개발자에게 검토 중 코드 적용 범위에 대한 명확한 아이디어를 제공합니다. 이 정보는 검토 속도를 높이고 새 코드를 병합 및 배포하는 시간을 줄이는 데 도움이 됩니다. 그리고 우리도 전환 가능한 기능(기능 플래그)을 스타터로 이동했습니다. 그리고 계획을 세우다 릴리스 13.5에서 Core로 이동.

그리고 이것은 시작에 불과합니다!

언제나 그렇듯이 일반 개요에는 공간이 너무 적지만 13.4 릴리스에는 멋진 기능이 많이 있습니다. 다음은 몇 가지 더 있습니다:

• 개인 액세스 토큰 목록을 확인하고 API를 통해 취소하세요.
• 자체 관리 자격 증명 저장소에 대한 개인 액세스 토큰 취소
• 완료된 할일을 디자인 페이지에 표시
• 중첩된 파이프라인(GitLab "조립 라인"의 러시아어 현지화)은 이제 자체 중첩 파이프라인을 실행할 수 있습니다.
• Helm 차트 GitLab에 대한 스마트 카드 인증 지원.

무엇이 당신을 기다리고 있는지 미리 알고 싶다면 следующем 풀어, 좀 봐 13.5 릴리스 비디오.

웹캐스트 "어려운 시대의 탄력성" 보기.

MVP 이번 달 - 파비오 후저

파비오가 크게 기여했습니다. 공헌 в 병합 요청 차이점에 코드 적용 범위 표시 - GitLab 커뮤니티에서 오랫동안 기다려온 기능입니다. 이는 GitLab 팀 구성원과의 지속적인 협업이 필요하고 UX, 프런트엔드 및 백엔드와 같은 프로젝트의 여러 영역에 영향을 미치는 사소한 변경에 대한 정말 중요한 기여입니다.

GitLab 13.4 릴리스의 주요 기능

CI 작업에 HashiCorp Vault 키 사용

(프리미엄, 얼티밋, 실버, 골드) DevOps 주기 단계: 릴리스

릴리스 12.10에서 GitLab은 GitLab 작업 핸들러(GitLab 러너)를 사용하여 CI 작업에 대한 키를 수신하고 전송하는 기능을 도입했습니다. 이제 우리는 확장하고 있습니다 JWT를 사용한 인증, 새로운 구문 추가 secrets 파일로 .gitlab-ci.yml. 이렇게 하면 GitLab에서 HashiCorp 저장소를 더 쉽게 설정하고 사용할 수 있습니다.

키 작업에 대한 문서 и 원래 티켓.

GitLab Kubernetes 에이전트 소개

(프리미엄, 얼티밋) DevOps 주기 단계: 구성

Kubernetes와 GitLab의 통합을 통해 오랫동안 수동 구성 없이 Kubernetes 클러스터에 배포하는 것이 가능해졌습니다. 많은 사용자가 이 번들의 사용 편의성을 좋아했지만 다른 사용자는 몇 가지 어려움을 겪었습니다. 현재 통합의 경우 GitLab이 클러스터에 액세스하려면 인터넷에서 클러스터에 액세스할 수 있어야 합니다. 많은 조직에서는 보안, 규정 준수 또는 규제상의 이유로 클러스터에 대한 액세스를 제한하기 때문에 이것이 불가능합니다. 이러한 제한 사항을 해결하려면 사용자는 GitLab을 기반으로 도구를 구축해야 했습니다. 그렇지 않으면 이 기능을 사용할 수 없습니다.

오늘 우리는 Kubernetes 클러스터에 배포하는 새로운 방법인 GitLab Kubernetes Agent를 소개합니다. 에이전트는 클러스터 내부에서 실행되므로 전체 인터넷에 노출할 필요가 없습니다. 에이전트는 GitLab이 클러스터에 업데이트를 푸시하는 대신 GitLab에서 새로운 변경 사항을 요청하여 배포를 조정합니다. 어떤 GitOps 방법을 사용하든 GitLab이 해결해 드립니다.

이것이 에이전트의 첫 번째 릴리스라는 점에 유의하십시오. GitLab Kubernetes Agent의 현재 초점은 코드를 통해 배포를 구성하고 관리하는 것입니다. 배포 보드 및 GitLab 관리 애플리케이션과 같은 일부 기존 Kubernetes 통합 기능은 아직 지원되지 않습니다. 우리는 가정한다이러한 기능은 보안 및 규정 준수에 초점을 맞춘 새로운 통합뿐만 아니라 향후 릴리스에서 에이전트에 추가될 예정입니다.

GitLab Kubernetes 에이전트 문서 и 원래 티켓.

코드 액세스 없이 사용자에게 배포 권한 부여

(프리미엄, 얼티밋, 실버, 골드) DevOps 주기 단계: 릴리스

이전에는 GitLab의 권한 시스템으로 인해 팀 내에서 개발 담당자와 배포 담당자 간에 책임을 적절하게 나누기가 어려웠습니다. GitLab 13.4가 출시되면서 배포용 병합 요청을 승인할 수 있는 권한을 부여할 수 있을 뿐만 아니라 관리자 액세스 권한을 부여하지 않고도 코드를 작성하지 않는 사람들에게 실제로 코드를 배포할 수 있는 권한을 부여할 수 있습니다(GitLab "유지관리자"의 러시아어 현지화) ).

환경 접근 문서 и 오리지널 서사시.

보안 센터

(궁극기, 골드) DevOps 주기 단계: 보안

이전에는 인스턴스 수준 취약성 관리가 기능과 유연성 모두에서 제한되었습니다. 인터페이스는 취약점, 측정항목 그래프, 설정에 대한 세부정보가 결합된 단일 페이지였습니다. 이러한 기능을 개발하거나 다른 보안 기능을 사용할 여지가 많지 않습니다.

우리는 GitLab에서 보안과 투명성을 관리하는 방법을 근본적으로 변경했습니다. 인스턴스 보안 패널이 전체 보안 센터로 전환되었습니다. 가장 큰 변화는 새로운 메뉴 구조의 도입입니다. 이제 한 페이지 대신 보안 대시보드, 취약점 보고서 및 설정 섹션이 별도로 표시됩니다. 기능은 변경되지 않았지만 여러 부분으로 나누면 다른 방법으로는 어려울 수 있는 이 섹션을 개선할 수 있습니다. 이는 또한 향후 다른 보안 관련 기능을 추가하기 위한 기반을 마련합니다.

이제 전용 취약점 보고서 섹션에 중요한 세부 정보를 표시할 수 있는 공간이 더 많아졌습니다. 현재 프로젝트의 취약점 목록에 있는 취약점은 다음과 같습니다. 취약점 지표가 포함된 위젯을 별도의 섹션으로 이동하면 편리한 보안 제어판이 생성됩니다. 이제 이는 취약성 관리뿐만 아니라 모든 보안 관련 지표에 대한 향후 시각화를 위한 캔버스입니다. 마지막으로 별도의 설정 영역은 취약점 관리뿐만 아니라 모든 인스턴스 수준의 보안 설정을 위한 공통 공간을 생성합니다.

인스턴스 보안 센터 문서 и 오리지널 서사시.

이제 전환 가능한 기능이 GitLab Starter에 있습니다.

(스타터, 프리미엄, 얼티메이트, 브론즈, 실버, 골드) DevOps 주기 단계: 릴리스

GitLab 11.4가 출시되었습니다. 전환 가능한 기능의 알파 버전. 12.2에서는 이를 위한 전략을 도입했습니다. 사용자 비율 и 사용자 ID별, 그리고 13.1에서는 추가되었습니다 사용자 목록 и 전략 수립 다양한 환경에 적합합니다.

올해 초 GitLab은 다음과 같은 약속을 했습니다. 18가지 기능 이동 오픈소스로. 이번 릴리스에서는 전환 가능한 기능을 스타터 플랜으로 마이그레이션하는 작업을 완료했으며 앞으로도 계속해서 Core로 마이그레이션할 예정입니다. 깃랩 13.5. 더 많은 사용자에게 이 기능을 제공하게 되어 기쁘게 생각하며, 이 기능을 어떻게 사용하는지 듣고 싶습니다.

전환 가능한 기능에 대한 문서 и 원래 티켓.

검색창을 통한 빠른 탐색

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) 가용성

때로는 GitLab을 탐색할 때 검색 결과 페이지가 아닌 특정 프로젝트로 바로 이동하고 싶을 때가 있습니다.

글로벌 검색창을 사용하면 최신 티켓, 그룹, 프로젝트, 설정 및 도움말 항목으로 빠르게 이동할 수 있습니다. 단축키를 사용해도 됩니다 /GitLab을 더욱 효율적으로 탐색하려면 커서를 검색 창으로 이동하세요!

자동 완성 문서 검색 и 원래 티켓.

병합 요청 차이점의 코드 적용 범위 표시

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 생성

병합 요청을 검토할 때 변경된 코드가 단위 테스트에 포함되는지 확인하기 어려울 수 있습니다. 대신 검토자는 병합 요청을 승인하기 전에 전체 적용 범위에 의존하여 범위를 늘려달라고 요청할 수 있습니다. 이는 테스트 작성에 대한 무계획적인 접근 방식으로 이어질 수 있으며, 이는 실제로 코드 품질이나 테스트 적용 범위를 향상시키지 않습니다.

이제 병합 요청 차이점을 볼 때 코드 적용 범위가 시각적으로 표시됩니다. 새로운 표시를 사용하면 변경된 코드가 단위 테스트에 포함되는지 여부를 빠르게 이해할 수 있으므로 코드 검토 속도를 높이고 새 코드를 병합 및 배포하는 시간을 단축하는 데 도움이 됩니다.

감사 파비오 후저 이 기능을 위해 Siemens가 필요합니다!

테스트별 코드 적용 범위 표시에 대한 문서 и 원래 티켓.

환경 패널의 더 많은 환경 및 프로젝트

(프리미엄, 얼티밋, 실버, 골드) DevOps 주기 단계: 릴리스

GitLab 12.5 출시 이후 환경 패널 환경 상태를 모니터링할 수 있지만 13.4개 프로젝트에서 XNUMX개 이하의 환경만 모니터링할 수 있습니다. 릴리스 XNUMX에서는 환경을 대규모로 유지 관리하는 데 도움이 되도록 페이지를 매겨 이 패널을 개선했습니다. 이제 더 많은 프로젝트에서 더 많은 환경을 볼 수 있습니다.

환경 패널 문서 и 원래 티켓.

GitLab은 GitLab Terraform 공급자를 제어합니다.

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 구성

우리는 최근 GitLab Terraform 공급자에 대한 관리자 권한을 받았습니다. 그리고 계획을 세우다 향후 릴리스에서 개선. 지난 한 달 동안 우리는 오래된 버그와 다음과 같은 누락된 기능을 포함하여 21개의 병합 요청을 수락하고 31개의 티켓을 마감했습니다. 인스턴스 클러스터 지원. 당신은 할 수 있습니다 GitLab Terraform 공급자에 대해 자세히 알아보세요. Terraform 문서에서.

GitLab Terraform 공급자 문서 и 원래 티켓.

OpenAPI 사양 또는 HAR 파일을 사용한 퍼징 API 테스트

(궁극기, 골드) DevOps 주기 단계: 보안

API 퍼징 테스트는 다른 스캐너와 테스트 방법이 놓칠 수 있는 웹 애플리케이션과 API의 버그와 취약성을 찾는 좋은 방법입니다.

GitLab의 API 퍼징 테스트를 통해 다음을 제공할 수 있습니다. OpenAPI v2 사양 또는 HAR 파일 그런 다음 극단적인 사례를 테스트하고 버그를 찾기 위해 설계된 무작위 입력 데이터를 자동으로 생성합니다. 결과는 파이프라인 내에서 즉시 표시됩니다.

이것은 우리의 첫 번째 API 퍼지 테스트 릴리스이며 여러분의 생각을 듣고 싶습니다. 퍼즈 테스트를 위한 재고가 더 많이 있습니다. 많은 아이디어, 이 기능의 출시를 기반으로 할 것입니다.

API 퍼징 테스트 문서 и 오리지널 서사시.

측정항목 패널에서 새 그래프 미리보기

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 모니터링

이전에는 GitLab의 지표 대시보드에서 그래프를 생성하는 것이 쉬운 작업이 아니었습니다. 대시보드 YAML 파일에서 지표를 생성한 후 다음을 변경했습니다. master, 새로 생성된 그래프가 필요한 대로 정확히 작동하는지 확인할 수 없습니다. 이번 릴리스부터 그래프를 생성하면서 변경 사항을 미리 보고 변경 사항을 대시보드 YAML 파일로 보내기 전에 결과를 확인할 수 있습니다.

패널에 새 그래프를 추가하는 방법에 대한 설명서 и 원래 티켓.

그룹 내 모든 프로젝트에 대한 테스트별 코드 커버리지 데이터

(프리미엄, 얼티밋, 실버, 골드) DevOps 주기 단계: 확인

GitLab에서 많은 수의 프로젝트를 관리하는 경우 모든 프로젝트에서 시간이 지남에 따라 코드 적용 범위가 어떻게 변화하는지에 대한 단일 정보 소스가 필요합니다. 이전에는 이 정보를 표시하려면 지루하고 시간이 많이 걸리는 수동 작업이 필요했습니다. 각 프로젝트에서 코드 적용 범위 데이터를 다운로드하여 테이블에 결합해야 했습니다.

릴리스 13.4에서는 쉽고 빠르게 조립이 가능해졌습니다. .csv 그룹의 모든 프로젝트 또는 선택한 프로젝트에 대한 코드 적용 범위에 대한 모든 데이터를 파일로 저장합니다. 이 기능은 MVC이며 다음 기능이 뒤따릅니다. 시간 경과에 따른 평균 적용 범위를 플롯합니다..

저장소 분석 문서 и 원래 티켓.

전체 퍼지 테스트를 위한 새로운 언어 지원

(궁극기, 골드) DevOps 주기 단계: 보안

이번 릴리스에서는 전체 범위를 목표로 하는 퍼지 테스트를 위한 여러 가지 새로운 언어에 대한 지원이 도입되었습니다.

이제 Java, Rust 및 Swift 애플리케이션에서 퍼징 테스트의 전체 기능을 평가하고 다른 스캐너 및 테스트 방법에서 놓칠 수 있는 오류와 취약점을 찾을 수 있습니다.

퍼지 테스트를 위해 지원되는 언어에 대한 문서 и 오리지널 서사시.

기본 환경 페이지의 경고

(프리미엄, 얼티밋, 실버, 골드) DevOps 주기 단계: 릴리스

환경 페이지에는 환경의 전반적인 상태가 표시됩니다. 이번 릴리스에서는 경고 표시를 추가하여 이 페이지를 개선했습니다. 환경 상태와 함께 트리거된 경고는 발생하는 상황을 수정하기 위해 신속하게 조치를 취하는 데 도움이 됩니다.

환경의 최신 경고를 보기 위한 설명서 и 원래 티켓.

이제 중첩된 파이프라인이 자체 중첩 파이프라인을 실행할 수 있습니다.

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 확인

중첩된 파이프라인을 사용하면 이제 하위 파이프라인 내에서 새 파이프라인을 실행할 수 있습니다. 가변적인 수의 파이프라인을 생성하는 유연성이 필요한 경우 추가 수준의 깊이가 유용할 수 있습니다.

이전에는 중첩된 파이프라인을 사용할 때 각 하위 파이프라인에서 상위 파이프라인에 트리거 작업을 수동으로 정의해야 했습니다. 이제 새로운 중첩 파이프라인을 원하는 만큼 동적으로 실행하는 중첩 파이프라인을 생성할 수 있습니다. 예를 들어 단일 저장소가 있는 경우 첫 번째 하위 파이프라인을 동적으로 생성할 수 있으며, 이 하위 파이프라인은 분기의 변경 사항에 따라 필요한 수의 새 파이프라인을 자체적으로 생성합니다.

중첩된 파이프라인 문서 и 원래 티켓.

상위 파이프라인과 중첩 파이프라인 간의 향상된 탐색

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 확인

이전에는 상위 파이프라인과 중첩 파이프라인 사이를 탐색하는 것이 그리 편리하지 않았습니다. 원하는 파이프라인에 도달하려면 많은 클릭이 필요했습니다. 어떤 작업이 파이프라인을 시작했는지 파악하는 것도 쉽지 않았습니다. 이제 상위 파이프라인과 중첩 파이프라인 간의 연결을 훨씬 쉽게 확인할 수 있습니다.

중첩된 파이프라인 문서 и 원래 티켓.

병렬 행렬 작업은 직위에 관련 변수를 표시합니다.

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 확인

사용한 경우 작업 매트릭스, 작업 이름이 다음과 같기 때문에 특정 작업에 어떤 행렬 변수가 사용되었는지 확인하기가 어렵다는 것을 알 수 있습니다. matrix 1/4. 릴리스 13.4에서는 일반 작업 이름 대신 해당 작업에 사용된 관련 변수 값이 표시됩니다. 예를 들어 x86 아키텍처를 디버깅하는 것이 목표라면 작업은 다음과 같이 호출됩니다. matrix: debug x86.

병렬 매트릭스 작업에 대한 문서 и 원래 티켓.

GitLab 13.4의 기타 개선 사항

Atlassian 계정 연결

(코어, 스타터, 프리미엄, 얼티밋) DevOps 주기 단계: 관리

이제 GitLab 사용자는 GitLab 계정을 Atlassian Cloud 계정에 연결할 수 있습니다. 이를 통해 Atlassian 자격 증명으로 GitLab에 로그인할 수 있으며 향후 통합 개선을 위한 토대가 마련될 것입니다. Jira가 포함된 Gitlab Atlassian 라인의 다른 제품과 함께 사용할 수 있습니다.

Atlassian 통합 문서 и 원래 티켓.

모든 병합 커밋 목록 내보내기

(궁극기, 골드) DevOps 주기 단계: 관리

규정 준수에 중점을 두는 조직에는 생산의 특정 변경 사항과 관련된 구성 요소에 대한 전체적인 보기를 감사자에게 보여줄 수 있는 방법이 필요합니다. GitLab에서 이는 병합 요청, 티켓, 파이프라인, 보안 검색, 기타 커밋 데이터 등 모든 것을 한 곳에 수집하는 것을 의미합니다. 지금까지는 정보를 GitLab에서 수동으로 수집하거나 정보를 수집하기 위한 도구를 구성해야 했는데 이는 그다지 효율적이지 않았습니다.

이제 프로그래밍 방식으로 이 데이터를 수집하고 내보내 감사 요구 사항을 충족하거나 다른 분석을 수행할 수 있습니다. 현재 그룹의 모든 병합 커밋 목록을 내보내려면 다음으로 이동해야 합니다. 규정 준수 대시보드 버튼을 클릭하십시오 모든 병합 커밋 목록. 결과 파일에는 병합 요청의 모든 커밋, 해당 작성자, 관련 병합 요청의 ID, 그룹, 프로젝트, 확인자 및 기타 정보가 포함됩니다.

보고서 작성을 위한 문서 и 원래 티켓.

API를 통해 개인 액세스 토큰 나열 및 관리

(궁극기, 골드) DevOps 주기 단계: 관리

GitLab 네임스페이스에 대한 액세스를 관리하는 것은 규정 준수 노력의 중요한 부분입니다. 최소 권한 원칙부터 시간 제한 액세스 비활성화까지 GitLab의 개인 액세스 토큰과 관련된 몇 가지 요구 사항이 있을 수 있습니다. 네임스페이스 내에서 이러한 모든 사용자 자격 증명을 더 쉽게 유지하고 관리할 수 있도록 모든 개인 액세스 토큰을 나열하고 선택적으로 나열하는 기능을 제공했습니다. 접근을 거부하다 API를 통해.

GitLab API에 대한 이러한 개선 사항을 통해 사용자는 자신의 개인 액세스 토큰을 나열하고 취소할 수 있으며, 관리자는 사용자의 토큰을 나열하고 취소할 수 있습니다. 이제 관리자는 자신의 네임스페이스에 액세스할 수 있는 사람을 확인하고, 사용자 데이터를 기반으로 액세스 결정을 내리고, 손상되었을 수 있거나 회사의 액세스 관리 정책을 벗어나는 개인 액세스 토큰을 취소하는 것이 더 쉬워졌습니다.

개인 액세스 토큰 문서 и 원래 티켓.

관련 문제 및 기타 기능이 이제 GitLab Core에 있습니다.

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 계획

몇 달 전에 우리는 다음과 같은 계획을 발표했습니다. 18가지 기능을 오픈 소스 코드로 번역. 이 약속을 이행하기 위해 노력함으로써 우리는 관련 티켓, 티켓을 CSV로 내보내기 и 작업 보드 집중 모드 (GitLab "토론 게시판"의 러시아어 현지화)은 Core 계획에서 사용할 수 있습니다. 이는 "연결된" 관계에만 적용되며 "차단" 및 "차단된" 관계는 유료 플랜에 유지됩니다.

관련 티켓에 대한 문서 и 원래 티켓.

병합 요청 사이드바에 원본 브랜치 이름 표시

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 생성

코드 변경, 토론, 병합 요청 커밋을 검토할 때 더 심층적인 검토를 위해 브랜치의 로컬 체크아웃을 수행하는 것이 바람직한 경우가 많습니다. 그러나 병합 요청 설명에 더 많은 콘텐츠가 추가되고 페이지 아래로 더 스크롤해야 하므로 스레드 이름을 찾는 것이 점점 더 어려워집니다.

병합 요청 사이드바에 분기 이름을 추가하여 언제든지 액세스할 수 있고 전체 페이지를 스크롤할 필요가 없습니다. 병합 요청 링크와 마찬가지로 소스 분기 섹션에는 편리한 "복사" 버튼이 포함되어 있습니다.

감사 에단 리저 이 기능 개발에 큰 기여를 해주셔서 감사합니다!

병합 요청 문서 и 원래 티켓.

병합 요청 차이점에 축소된 파일이 있음을 나타냅니다.

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 생성

여러 파일에 변경 사항을 추가하는 병합 요청은 렌더링 성능을 향상시키기 위해 대용량 파일의 차이점을 축소하는 경우도 있습니다. 이런 일이 발생하면 특히 많은 수의 파일이 포함된 병합 요청에서 검토 중에 실수로 파일을 건너뛸 수 있습니다. 버전 13.4부터 병합 요청은 접힌 파일이 포함된 diff에 플래그를 지정하므로 코드 검토 중에 이러한 파일을 놓치지 않을 것입니다. 더욱 명확하게 하기 위해 향후 릴리스에서는 이러한 파일에 강조 표시를 추가할 계획입니다. 다음 업데이트를 계속 지켜봐주세요 gitlab 티켓#16047.

병합 요청 차이점의 접힌 파일에 대한 문서 и 원래 티켓.

병합 요청의 diff에 축소된 파일이 있다는 경고

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 생성

병합 요청 diff 섹션에서는 성능 향상을 위해 대용량 파일이 축소됩니다. 그러나 코드를 검토할 때 대용량 파일은 모두 축소되므로 검토자가 파일 목록을 스크롤할 때 일부 파일이 누락될 수 있습니다.

이 섹션에 병합된 파일이 있음을 사용자에게 알리기 위해 병합 요청 diff 페이지 상단에 표시되는 경고를 추가했습니다. 이렇게 하면 검토 중에 병합 요청에 대한 변경 사항을 놓치지 않을 수 있습니다.

병합 요청 차이점의 접힌 파일에 대한 문서 и 원래 티켓.

Gitaly 클러스터 저장소 자동 복구

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 생성

이전에는 Gitaly 클러스터의 기본 노드가 오프라인 상태가 되면 해당 노드의 리포지토리가 읽기 전용으로 표시되었습니다. 이는 아직 복제되지 않은 노드에 변경 사항이 있는 상황에서 데이터 손실을 방지했습니다. 노드가 다시 온라인 상태가 되었을 때 GitLab은 자동으로 복원되지 않았으며 관리자는 수동으로 동기화 프로세스를 시작하거나 데이터 손실을 허용해야 했습니다. 보조 노드의 복제 작업 실패와 같은 다른 상황으로 인해 리포지토리가 오래되거나 읽기 전용이 될 수도 있습니다. 이 경우 복제 작업을 시작하는 다음 쓰기 작업이 발생할 때까지 리포지토리는 오래된 상태로 유지되었습니다.

이 문제를 해결하려면 총독 이제 한 노드에서 오래된 저장소를 감지하고 다른 노드에서 최신 버전의 저장소를 감지하면 복제 작업을 예약합니다. 이 복제 작업은 리포지토리를 자동으로 최신 상태로 유지하므로 데이터를 수동으로 복원할 필요가 없습니다. 또한 자동 복구를 통해 복제 작업이 실패할 경우 다음 쓰기 작업을 기다리지 않고 보조 노드를 신속하게 최신 상태로 유지할 수 있습니다. 많은 Gilaly 클러스터는 많은 수의 리포지토리를 저장하므로 관리자와 안정성 엔지니어가 오류 발생 후 데이터를 복구하는 데 소요되는 시간이 크게 줄어듭니다.

또한 자동 복구는 클러스터에 추가된 새 Gitaly 노드에서 리포지토리 복제를 시작하므로 새 노드를 추가할 때 수동 작업이 필요하지 않습니다.

Gitaly 데이터 복구 문서 и 원래 티켓.

디자인 페이지에서 할 일을 완료로 표시하세요.

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 생성

GitLab의 효과적인 의사소통은 할 일 목록을 기반으로 합니다. 댓글에 자신이 언급된 경우 작업으로 바로 이동하여 작업을 시작하거나 완료로 표시할 수 있는 것이 중요합니다. 어떤 일을 해야 하거나 나중에 다시 해야 할 때 자신에게 작업을 할당할 수 있는 것도 중요합니다.

이전에는 디자인 작업 시 작업을 추가하거나 완료된 것으로 표시할 수 없었습니다. 해야 할 일은 GitLab 워크플로의 중요한 요소이기 때문에 이로 인해 제품 팀 간의 의사소통 효율성이 심각하게 저하되었습니다.

릴리스 13.4에서는 작업 사용 시 티켓 댓글을 따라잡는 디자인이 있어 작업을 보다 일관되고 효율적으로 수행할 수 있습니다.

디자인 작업 추가에 대한 문서 и 원래 티켓.

CI/CD 문제 해결 가이드 개선

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 확인

발생할 수 있는 일반적인 문제에 대한 추가 정보를 포함하여 GitLab CI/CD 문제 해결 가이드를 개선했습니다. 개선된 문서가 GitLab CI/CD를 빠르고 쉽게 시작하고 실행하는 데 도움이 되는 귀중한 리소스가 되기를 바랍니다.

CI/CD 문제 해결 문서 и 원래 티켓.

병합 요청이 더 이상 병합 대기열에서 벗어나지 않습니다.

(프리미엄, 얼티밋, 실버, 골드) DevOps 주기 단계: 확인

이전에는 주석이 늦어져 병합 요청이 실수로 병합 대기열에서 벗어날 수 있었습니다. 병합 요청이 이미 대기열에 있고 누군가가 여기에 설명을 추가하여 해결되지 않은 새 토론을 생성한 경우 병합 요청은 병합에 적합하지 않은 것으로 간주되어 대기열에서 제외됩니다. 이제 병합 요청이 병합 대기열에 추가된 후 병합 프로세스가 중단될 염려 없이 새 주석을 추가할 수 있습니다.

병합 대기열 문서 и 원래 티켓.

병합 요청에서 작업에 대한 코드 적용 범위 값 표시

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 확인

개발자는 파이프라인이 완료된 후 코드 적용 범위 값을 볼 수 있어야 합니다. 적용 범위 값을 계산하기 위해 구문 분석해야 하는 여러 작업이 포함된 파이프라인을 실행하는 것과 같은 복잡한 시나리오에서도 마찬가지입니다. 이전에는 병합 요청 위젯에 이러한 값의 평균만 표시되었습니다. 즉, 중간 적용 범위 값을 얻으려면 작업 페이지로 이동한 다음 병합 요청으로 다시 돌아가야 했습니다. 시간과 이러한 추가 단계를 절약하기 위해 위젯에 평균 적용 범위 값, 대상 분기와 소스 분기 간의 변경 사항, 평균이 계산된 기준으로 각 작업에 대한 적용 범위 값을 표시하는 도구 설명이 표시되도록 만들었습니다.

코드 적용 범위 구문 분석 문서 и 원래 티켓.

그룹을 볼 때 패키지 레지스트리에서 패키지 제거

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 패키지

GitLab 패키지 레지스트리는 패키지를 다양한 형식으로 저장하고 배포하는 장소입니다. 프로젝트나 그룹에 패키지가 많으면 사용하지 않는 패키지를 신속하게 식별하고 제거하여 사람들이 다운로드하지 못하도록 해야 합니다. 다음을 통해 레지스트리에서 패키지를 제거할 수 있습니다. 패키지 API 또는 패키지 레지스트리 사용자 인터페이스를 통해. 그러나 지금까지는 UI를 통해 그룹을 볼 때 패키지를 제거할 수 없었습니다. 결과적으로 프로젝트별로 불필요한 패키지를 제거해야 했기 때문에 비효율적이었습니다.

이제 그룹의 패키지 레지스트리를 볼 때 패키지를 제거할 수 있습니다. 그룹의 패키지 등록 페이지로 이동하여 이름별로 패키지를 필터링하고 필요하지 않은 패키지를 제거하면 됩니다.

패키지 레지스트리에서 패키지 제거에 대한 문서 и 원래 티켓.

Conan 패키지를 프로젝트 수준으로 확장

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 패키지

GitLab의 Conan 저장소를 사용하여 C/C++ 종속성을 게시하고 배포할 수 있습니다. 그러나 Conan 패키지 이름은 최대 51자까지만 가능했기 때문에 이전 패키지는 인스턴스 수준으로만 확장할 수 있었습니다. 예를 들어 하위 그룹에서 패키지를 게시하려는 경우 gitlab-org/ci-cd/package-stage/feature-testing/conan, 거의 불가능했습니다.

이제 Conan 패키지를 프로젝트 수준으로 축소하여 프로젝트의 종속성을 쉽게 게시하고 배포할 수 있습니다.

Conan 패키지 출판 문서 и 원래 티켓.

종속성 검사를 위한 새로운 패키지 관리자 및 언어 지원

(궁극기, 골드) DevOps 주기 단계: 보안

NuGet 4.9+ 또는 Conan 패키지 관리자를 사용하는 C, C++, C# 및 .Net 코드 프로젝트에 대한 종속성 검사를 목록에 추가하게 되어 기쁘게 생각합니다. 지원되는 언어 및 프레임워크. 이제 보안 단계의 일부로 종속성 검색을 활성화하여 패키지 관리자를 통해 추가된 종속성의 알려진 취약점을 확인할 수 있습니다. 발견된 취약점은 심각도 수준과 함께 병합 요청에 표시되므로 병합을 실행하기 전에 새 종속성이 수반하는 위험이 무엇인지 알 수 있습니다. 또한 다음을 요구하도록 프로젝트를 구성할 수도 있습니다. 병합 요청 확인 심각도(Critical), 높음(High) 또는 알 수 없음(Unknown) 심각도 수준의 취약점이 있는 종속성의 경우.

지원되는 언어 및 패키지 관리자에 대한 문서 и 오리지널 서사시.

병합 요청 설정을 '파이프라인이 성공적으로 완료되면 병합'으로 변경할 때 알림

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 릴리스

이전에는 병합 요청 설정을 할 때 파이프라인이 완료되면 병합 (파이프라인 성공 시 병합, MWPS) 이메일 알림이 전송되지 않았습니다. 수동으로 상태를 확인하거나 병합 알림을 기다려야 했습니다. 이번 릴리스를 통해 우리는 사용자 기여를 제공하게 된 것을 기쁘게 생각합니다. @ravishankar2kool에서는 검토자가 병합 설정을 MWPS로 변경할 때 병합 요청을 구독하는 모든 사람에게 자동 알림을 추가하여 이 문제를 해결했습니다.

병합 요청 이벤트 알림에 대한 문서 и 원래 티켓.

사용자가 지정한 Kubernetes 버전으로 EKS 클러스터 생성

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 구성

이제 GitLab 사용자는 EKS에서 제공할 Kubernetes 버전을 선택할 수 있습니다. 버전 1.14~1.17 중에서 선택할 수 있습니다.

EKS 클러스터 추가에 대한 설명서 и 원래 티켓.

티켓 유형으로 사건 만들기

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 모니터링

발생하는 모든 문제가 즉시 경고를 트리거하는 것은 아닙니다. 사용자는 중단을 보고하고 팀 구성원은 성능 문제를 조사합니다. 사건은 이제 일종의 티켓이므로 팀은 일반적인 워크플로의 일부로 신속하게 사건을 생성할 수 있습니다. 딸깍 하는 소리 새 작업 GitLab과 현장 어디에서나 유형 선택 사건.

인시던트 수동 생성에 대한 문서 и 원래 티켓.

Markdown에서 GitLab 경고 언급

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 모니터링

GitLab Markdown에 특별히 새로운 언급 유형을 추가하여 GitLab 경고를 개선하여 경고를 더 쉽게 공유하고 언급할 수 있게 했습니다. 사용 ^alert#1234사건, 티켓, 병합 요청 등 마크다운 필드에서 알림을 언급할 수 있습니다. 이는 티켓이나 병합 요청이 아닌 알림으로 생성된 작업을 식별하는 데도 도움이 됩니다.

사고 관리 문서 и 원래 티켓.

사건별 경보 부하 보기

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 모니터링

경고 설명에는 문제 해결 및 복구에 중요한 정보가 포함되어 있으며, 이 정보는 문제를 해결하기 위해 작업할 때 도구나 탭을 전환할 필요가 없도록 쉽게 액세스할 수 있어야 합니다. 경고에서 생성된 사건은 탭에 전체 경고 설명을 표시합니다. 경고 세부정보.

75% 더 빠른 고급 검색

(스타터, 프리미엄, 얼티메이트, 브론즈, 실버, 골드) 가용성

단일 애플리케이션인 GitLab은 전체 DevOps 워크플로에서 콘텐츠를 빠르게 검색할 수 있는 고유한 기능을 갖추고 있습니다. GitLab 13.4에서는 고급 검색이 다음과 같은 경우 결과를 75% 더 빠르게 반환합니다. 특정 네임스페이스 및 프로젝트로 제한됨, GitLab.com에서와 같습니다.

더 빠른 고급 검색 문서 и 원래 티켓.

관리자를 위해 삭제된 프로젝트 보기

(코어, 스타터, 프리미엄, 얼티밋) DevOps 주기 단계: 관리

프로젝트 삭제를 연기하는 옵션이 있었습니다. 12.6에 도입됨. 그러나 이전에는 삭제 대기 중인 모든 프로젝트를 한 곳에서 볼 수 없었습니다. GitLab 사용자 인스턴스 관리자는 이제 해당 프로젝트를 쉽게 복원할 수 있는 버튼과 함께 한 곳에서 보류 중인 모든 삭제 프로젝트를 볼 수 있습니다.

이 기능을 사용하면 모든 관련 정보를 한곳에 수집하고 원치 않는 삭제 작업을 취소할 수 있는 기능을 제공하여 관리자가 프로젝트 삭제를 보다 효과적으로 제어할 수 있습니다.

감사 아쉬쉬 비듀트(@asheshvidyut7) 이 기능을 위해!

프로젝트 삭제에 대한 문서 и 원래 티켓.

API에 그룹 푸시 규칙에 대한 지원이 추가되었습니다.

(스타터, 프리미엄, 얼티메이트, 브론즈, 실버, 골드) DevOps 주기 단계: 관리

이전에는 GitLab UI를 통해 각 그룹을 개별적으로 방문하고 해당 규칙을 적용해야만 그룹 푸시 규칙을 구성할 수 있었습니다. 이제 API를 통해 이러한 규칙을 관리하여 사용자 정의 도구 및 GitLab 자동화를 지원할 수 있습니다.

그룹의 푸시 규칙에 대한 문서 и 원래 티켓.

자체 관리 자격 증명 저장소에 대한 개인 액세스 토큰 취소

(궁극적인) DevOps 주기 단계: 관리

자격증명 저장 관리자에게 GitLab 인스턴스에 대한 사용자 자격 증명을 관리하는 데 필요한 정보를 제공합니다. 규정 준수에 중점을 두는 조직마다 자격 증명 관리 정책의 엄격함이 다르기 때문에 관리자가 선택적으로 사용자의 PAT(개인 액세스 토큰)를 취소할 수 있는 버튼을 추가했습니다. 이제 관리자는 잠재적으로 손상된 PAT를 쉽게 취소할 수 있습니다. 이 기능은 사용자의 업무 중단을 최소화하기 위해 보다 유연한 규정 준수 옵션을 원하는 조직에 유용합니다.

자격 증명 저장소 문서 и 원래 티켓.

정적 사이트 편집기용 구성 파일

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 생성

GitLab 13.4에서는 정적 사이트 편집기를 사용자 정의하는 새로운 방법을 도입합니다. 이번 릴리스에서는 구성 파일이 어떤 설정도 저장하거나 수신하지 않지만, 향후 편집기 동작 사용자 정의를 위한 기반을 마련하고 있습니다. 향후 릴리스에서는 파일에 추가할 예정입니다. .gitlab/static-site-editor.yml 설치 매개변수 기본 사이트 주소, 어느 편집기에 로드된 이미지가 저장됩니다., Markdown 구문 설정 및 기타 편집기 설정을 재정의합니다.

정적 사이트 편집기 설정에 대한 문서 и 오리지널 서사시.

정적 사이트 편집기를 사용하여 파일의 소개 부분 편집

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 생성

머리말은 정적 사이트 생성기에서 처리할 데이터 파일의 페이지 변수를 정의하는 유연하고 편리한 방법입니다. 일반적으로 페이지 제목, 레이아웃 템플릿 또는 작성자를 설정하는 데 사용되지만 HTML로 페이지를 렌더링할 때 모든 유형의 메타데이터를 생성기에 전달하는 데 사용할 수 있습니다. 모든 데이터 파일의 맨 위에 포함된 소개 부분은 일반적으로 YAML 또는 JSON 형식으로 구성되며 일관되고 정확한 구문이 필요합니다. 특정 구문 규칙에 익숙하지 않은 사용자는 실수로 잘못된 마크업을 입력할 수 있으며, 이로 인해 형식 지정 문제가 발생하거나 빌드 오류가 발생할 수도 있습니다.

정적 사이트 편집기의 WYSIWYG 편집 모드는 이러한 형식 오류를 방지하기 위해 이미 편집기에서 소개를 제거합니다. 하지만 이렇게 하면 소스 모드에서 편집으로 돌아가지 않고 이 부분에 저장된 값을 변경할 수 없습니다. GitLab 13.4에서는 친숙한 양식 기반 인터페이스에서 모든 필드에 액세스하고 해당 값을 편집할 수 있습니다. 버튼을 눌렀을 때 설정 (설정) 처음에 정의된 각 키에 대한 양식 필드를 보여주는 패널이 열립니다. 필드는 현재 값으로 채워지며, 편집은 웹 양식에 입력하는 것만큼 간단합니다. 이러한 방식으로 소개를 편집하면 복잡한 구문이 방지되고 최종 결과의 형식이 일관되게 유지되면서 콘텐츠를 완벽하게 제어할 수 있습니다.

정적 사이트 편집기 문서 и 원래 티켓.

Jira 및 DVCS 커넥터용 GitLab이 이제 코어에 있습니다.

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 생성

GitLab의 Jira 사용자의 경우: Jira용 GitLab 앱 и DVCS 커넥터 GitLab 커밋 및 병합 요청에 대한 정보를 Jira에 직접 표시할 수 있습니다. 내장된 Jira 통합 기능과 결합하면 작업하면서 두 앱 사이를 쉽게 이동할 수 있습니다.

이러한 기능은 이전에는 프리미엄 플랜에서만 사용할 수 있었지만 이제는 모든 사용자가 사용할 수 있습니다!

Jira 통합 문서 и 원래 티켓.

Gitaly 클러스터 트랜잭션에 대한 다수 투표(베타)

(코어, 스타터, 프리미엄, 얼티밋) DevOps 주기 단계: 생성

Gitaly 클러스터를 사용하면 Git 리포지토리를 여러 "웜" Gitaly 노드에 복제할 수 있습니다. 이는 단일 실패 지점을 제거하여 내결함성을 향상시킵니다. 거래 운영GitLab 13.3에 도입된 , 변경 사항은 클러스터의 모든 Gitaly 노드에 브로드캐스트되지만 기본 노드에 동의하는 Gitaly 노드만 변경 사항을 디스크에 저장합니다. 모든 복제본 노드가 동의하지 않으면 변경 사항의 복사본 하나만 디스크에 저장되어 비동기식 복제가 완료될 때까지 단일 실패 지점이 생성됩니다.

다수결 투표는 변경 사항을 디스크에 저장하기 전에 다수의 노드(전체는 아님)의 동의를 요구하여 내결함성을 향상시킵니다. 이 토글 기능이 활성화되면 여러 노드에서 쓰기가 성공해야 합니다. 반대 노드는 쿼럼을 구성한 노드의 비동기 복제를 사용하여 자동으로 동기화됩니다.

Gitaly의 일관성 설정에 대한 문서 и 원래 티켓.

Web IDE에서 JSON 유효성 검사를 위한 사용자 정의 스키마 지원

(프리미엄, 얼티밋, 실버, 골드) DevOps 주기 단계: 생성

사람들이 JSON 또는 YAML로 구성을 작성하는 프로젝트는 오타가 발생하고 무언가가 깨지기 쉽기 때문에 종종 문제가 발생하기 쉽습니다. CI 파이프라인에서 이러한 문제를 포착하기 위한 검사 도구를 작성할 수 있지만 JSON 스키마 파일을 사용하면 문서와 힌트를 제공하는 데 유용할 수 있습니다.

프로젝트 참가자는 저장소에서 파일의 사용자 정의 스키마 경로를 정의할 수 있습니다. .gitlab/.gitlab-webide.yml, 확인할 파일의 스키마와 경로를 지정합니다. 특정 파일을 Web IDE에 로드하면 파일을 생성하는 데 도움이 되는 추가 피드백과 유효성 검사가 표시됩니다.

Web IDE의 사용자 정의 스키마에 대한 문서 и 원래 티켓.

DAG(방향성 비순환 그래프) 분기 제한이 50으로 증가했습니다.

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 확인

컨베이어를 사용하는 경우 방향성 비순환 그래프 포함 (DAG(방향성 비순환 그래프))에서 작업이 지정할 수 있는 작업은 10개로 제한되어 있음을 알 수 있습니다. needs:, 너무 가혹합니다. 13.4에서는 파이프라인의 작업 간 관계의 더 복잡한 네트워크를 허용하기 위해 기본 제한이 10에서 50으로 늘어났습니다.

사용자 정의 GitLab 인스턴스의 관리자인 경우 토글 기능을 설정하여 이 제한을 더 높일 수 있습니다. 단 이에 대한 공식 지원은 제공하지 않습니다.

Документация по настройке needs: и 원래 티켓.

개선된 동작 needs 놓친 과제에 대해

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 확인

경우에 따라 파이프라인에서 누락된 작업이 지정된 종속성에 대해 성공한 것으로 잘못 간주될 수 있습니다. needs, 이로 인해 발생해서는 안 되는 후속 작업이 실행되었습니다. 이 동작은 버전 13.4에서 수정되었으며 needs 이제 누락된 작업 사례를 올바르게 처리합니다.

Документация по настройке needs и 원래 티켓.

삭제되지 않도록 마지막 퀘스트 아티팩트를 고정하세요.

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 확인

이제 GitLab은 만료 후 삭제되는 것을 방지하기 위해 활성 분기, 병합 요청 또는 태그에서 마지막으로 성공한 작업 및 파이프라인 아티팩트를 자동으로 잠급니다. 오래된 아티팩트를 정리하기 위해 더욱 공격적인 만료 규칙을 설정하는 것이 더 쉬워졌습니다. 이렇게 하면 디스크 공간 소비를 줄이고 항상 파이프라인의 최신 아티팩트 복사본을 유지할 수 있습니다.

아티팩트 만료에 관한 문서 и 원래 티켓.

파이프라인 최적화를 위한 CI/CD 가이드

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 확인

CI/CD 파이프라인을 최적화하면 전송 속도를 향상하고 비용을 절감할 수 있습니다. 파이프라인 최적화를 최대한 활용하기 위한 빠른 가이드를 포함하도록 설명서를 개선했습니다.

컨베이어 효율성 향상에 관한 문서 и 원래 티켓.

테스트 상태별로 정렬된 테스트 보고서

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 확인

단위 테스트 보고서 파이프라인의 모든 테스트 결과를 쉽게 볼 수 있는 방법입니다. 그러나 테스트 수가 많으면 실패한 테스트를 찾는 데 시간이 오래 걸릴 수 있습니다. 보고서를 사용하기 어렵게 만들 수 있는 다른 문제로는 긴 추적 출력을 스크롤하는 데 어려움이 있고 1초 이내에 실행되는 테스트의 경우 XNUMX으로 반올림되는 시간이 포함됩니다. 이제 기본적으로 테스트 보고서를 정렬할 때 먼저 실패한 테스트를 보고서 시작 부분에 배치한 다음 테스트를 기간별로 정렬합니다. 이렇게 하면 실패와 긴 테스트를 더 쉽게 찾을 수 있습니다. 또한 테스트 기간이 이제 밀리초 또는 초 단위로 표시되므로 훨씬 더 빠르게 읽을 수 있으며 이전 스크롤 문제도 해결되었습니다.

단위 테스트 보고 문서 и 원래 티켓.

패키지 레지스트리에 업로드되는 파일 크기 제한

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 패키지

이제 GitLab 패키지 레지스트리에 업로드할 수 있는 패키지 파일의 크기에 제한이 있습니다. 패키지 레지스트리 성능을 최적화하고 남용을 방지하기 위해 제한 사항이 추가되었습니다. 한도는 패키지 형식에 따라 다릅니다. GitLab.com의 경우 최대 파일 크기는 다음과 같습니다.

• 코난: 250MB
• 메이븐: 3GB
• NPM: 300MB
• NuGet: 250MB
• PyPI: 3GB

사용자 정의 GitLab 인스턴스의 경우 기본값은 동일합니다. 그러나 관리자는 다음을 사용하여 제한 사항을 업데이트할 수 있습니다. 레일스 콘솔.

파일 크기 제한에 대한 문서 и 원래 티켓.

CI_JOB_TOKEN을 사용하여 PyPI 패키지 게시

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 패키지

GitLab PyPI 리포지토리를 사용하여 소스 코드 및 CI/CD 파이프라인과 함께 Python 패키지를 생성, 게시 및 공유할 수 있습니다. 그러나 이전에는 사전 정의된 환경 변수를 사용하여 저장소에 인증할 수 없었습니다. CI_JOB_TOKEN. 결과적으로 개인 자격 증명을 사용하여 PyPI 저장소를 업데이트해야 하거나 저장소를 전혀 사용하지 않기로 결정했을 수도 있습니다.

이제 GitLab CI/CD를 사용하여 사전 정의된 환경 변수를 사용하여 PyPI 패키지를 게시하고 설치하는 것이 더 쉬워졌습니다. CI_JOB_TOKEN.

PyPI 패키지와 함께 GitLab CI 사용에 대한 문서 и 원래 티켓.

요청 시 DAST 스캐너 프로필

(궁극기, 골드) DevOps 주기 단계: 보안

주문형 DAST 스캔에 이전 릴리스에 소개된, DAST 스캐너 프로필이 추가되었습니다. 이러한 스캔의 구성 기능을 확장하여 여러 스캔 유형을 포괄하는 여러 프로필을 빠르게 생성할 수 있습니다. 13.4의 크롤러 프로필에는 DAST 크롤러가 크롤링된 사이트의 모든 페이지를 검색하려고 시도할 때 실행해야 하는 시간을 설정하는 크롤러 시간 초과 설정이 기본적으로 포함되어 있습니다. 프로필에는 사이트가 200 또는 300 상태 코드로 응답하지 않는 경우 크롤링을 중단하기 전에 크롤러가 사이트에 액세스할 수 있을 때까지 기다려야 하는 시간을 설정하는 대상 사이트 시간 초과 설정도 포함되어 있습니다. 향후 릴리스에서는 스캐너 프로필에 추가되며 추가 구성 매개변수가 추가될 예정입니다.

DAST 스캐너 프로필 문서 и 원래 티켓.

GitLab 페이지에 대한 간단한 리디렉션 구성 파일

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 릴리스

GitLab 페이지를 사용하고 URL 변경 사항을 더 잘 관리하려는 경우 GitLab 페이지 사이트에서 리디렉션 관리가 불가능하다는 것을 알 수 있습니다. 이제 GitLab을 사용하면 저장소에 구성 파일을 추가하여 페이지 사이트의 한 URL을 다른 URL로 리디렉션하는 규칙을 구성할 수 있습니다. 이 기능은 Kevin Barnett(@PopeDrFreud), 우리의 Eric Eastwood(@MadLittleMods) 및 GitLab 팀. 귀하의 의견에 감사드립니다.

문서 리디렉션 и 원래 티켓.

GitLab에서 관리하는 Terraform 상태

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 구성

필요한 경우 규정 준수 및 디버깅을 위해 이전 버전의 Terraform 상태에 액세스해야 합니다. GitLab에서 관리하는 Terraform 상태 버전 관리 지원은 GitLab 13.4부터 제공됩니다. 새로운 Terraform 상태 파일에 대해 버전 관리가 자동으로 활성화됩니다. 기존 Terraform 상태 파일은 버전이 지정된 저장소로 자동 마이그레이션됨 이후 릴리스에서.

GitLab에서 관리하는 Terraform 상태에 대한 문서 и 원래 티켓.

중요한 사건 알림 세부정보

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 모니터링

인시던트를 처리할 때 경고가 열린 기간과 이벤트가 트리거된 횟수를 쉽게 확인할 수 있어야 합니다. 이러한 세부 정보는 고객에게 미치는 영향과 팀이 먼저 해결해야 할 사항을 결정하는 데 중요한 경우가 많습니다. 새로운 사건 세부 정보 패널에는 경고 시작 시간, 이벤트 수 및 원래 경고에 대한 링크가 표시됩니다. 이 정보는 경고에서 생성된 인시던트에 사용할 수 있습니다.

사고 관리 문서 и 오리지널 서사시.

사고 심각도 매개변수 설정 및 편집

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) DevOps 주기 단계: 모니터링

사고 심각도 차원을 통해 대응자와 이해관계자는 가동 중단의 영향은 물론 대응 방법과 긴급성을 결정할 수 있습니다. 팀에서 사고 해결 및 복구 중에 결과를 공유할 때 이 설정을 변경할 수 있습니다. 이제 사건 세부 정보 페이지의 오른쪽 사이드바에서 사건의 심각도를 편집할 수 있으며 심각도가 사건 목록에 표시됩니다.

사고 처리를 위한 문서 и 원래 티켓.

컨테이너 네트워크 보안 규칙 생성, 편집 및 삭제

(궁극기, 골드) DevOps 주기 단계: 방어

컨테이너 네트워크 보안 규칙 편집기의 향상된 기능을 통해 사용자는 GitLab 사용자 인터페이스에서 직접 규칙을 쉽게 생성, 편집 및 삭제할 수 있습니다. 편집기 기능은 다음과 같습니다 .yaml 숙련된 사용자를 위한 것이며 네트워크 규칙을 처음 접하는 사용자를 위한 직관적인 인터페이스를 갖춘 규칙 편집기입니다. 섹션에서 새로운 규칙 관리 옵션을 찾을 수 있습니다. 보안 및 규정 준수 > 위협 관리 > 규칙 (보안 및 규정 준수 > 위협 관리 > 정책).

네트워크 규칙 편집기 문서 и 오리지널 서사시.

Azure Blob 저장소 지원

(코어, 스타터, 프리미엄, 얼티메이트, 무료, 브론즈, 실버, 골드) 가용성

이제 GitLab과 GitLab Runner가 모두 지원됩니다. Azure Blob 저장소, Azure에서 GitLab 서비스를 더 쉽게 실행할 수 있습니다.

GitLab 인스턴스는 LFS 파일, CI 아티팩트를 포함한 모든 유형의 개체 저장소에 대해 Azure를 지원합니다. 백업. Azure Blob Storage를 설정하려면 설치 지침을 따르세요. 옴니버스 또는 헬름 차트.

GitLab 작업 프로세서는 저장을 위해 Azure도 지원합니다. 분산 캐시. Azure Storage는 섹션을 사용하여 구성할 수 있습니다. [runners.cache.azure].

Azure Blob Storage 사용에 대한 설명서 и 원래 티켓.

Ubuntu 및 OpenSUSE용 Omnibus ARM64 패키지

(코어, 스타터, 프리미엄, 얼티밋) 가용성

64비트 ARM 아키텍처에서 GitLab을 실행하기 위한 지원에 대한 수요가 증가함에 따라 공식 ARM64 Ubuntu 20.04 Omnibus 패키지의 출시를 발표하게 된 것을 기쁘게 생각합니다. 큰 공헌을 해주신 Zitai Chen과 Guillaume Gardet에게 큰 감사를 드립니다. 이들의 병합 요청이 여기서 중요한 역할을 했습니다!

Ubuntu 20.04용 패키지를 다운로드하고 설치하려면 다음으로 이동하세요. 설치 페이지 그리고 선택 Ubuntu.

ARM64용 패키지 문서 и 원래 티켓.

GitLab Helm 차트에 대한 스마트 카드 인증 지원

(프리미엄, 얼티밋) 가용성

이제 CAC(Common Access Card)와 같은 스마트 카드를 사용하여 Helm 차트를 통해 배포된 GitLab 인스턴스를 인증할 수 있습니다. 스마트 카드는 X.509 인증서를 사용하여 로컬 데이터베이스에 대해 인증됩니다. 이를 통해 Helm 차트의 스마트 카드 지원은 이제 Omnibus 배포에서 사용 가능한 스마트 카드 지원과 일치합니다.

스마트 카드 인증 설정 설명서 и 원래 티켓.

자세한 릴리스 노트와 업데이트/설치 지침은 원본 영어 게시물에서 읽을 수 있습니다. CI 변수 및 Kubernetes 에이전트용 Vault와 함께 출시된 GitLab 13.4.

우리는 영어 번역 작업을 하고 있었습니다. 카티두르덴, 메리아트키, 아이노네코 и 리샤반트.

출처 : habr.com