버전에 따른 폐지 사항 및 제거 사항

다음은 GitLab 기능이 폐지되었으며 더 이상 사용을 권장하지 않습니다.

• 각각의 폐지된 기능은 향후 릴리스에서 제거됩니다.
• 일부 기능이 제거되면 파격적인 변화가 발생합니다.
• GitLab.com에서는 폐지된 기능이 릴리스 이전 한 달 동안 언제든지 제거될 수 있습니다.

이 폐지 정보를 고급 검색 및 필터링하려면 고객 성공팀이 작성한 도구를 사용해보세요.

REST API 폐지 사항 및 GraphQL 폐지 사항 은 별도로 문서화되어 있습니다.

다가오는 파격적인 변화에 대한 통보를 받으려면, 이 URL을 RSS 피드 리더에 추가하세요: https://about.gitlab.com/breaking-changes.xml

GitLab 18.0

scan 실행 정책에서의 제한된 작업

GitLab 18.0부터 스캔 실행 정책 은 정책당 최대 10개의 scan 작업으로 제한됩니다. 이 제한을 초과하는 새로운 정책을 생성하거나 기존의 정책을 업데이트할 수 없습니다. 제한을 초과하는 기존 정책의 경우, 최초 10개의 scan 작업만 실행됩니다.

scan_execution_policies_action_limit 응용 프로그램 설정을 사용하여 Self-Managed 인스턴스에 사용자 정의 제한을 구성할 수 있습니다.

</div>

PipelineSchedulePermissions에서 GraphQL 필드 take_ownership_pipeline_schedule를 admin_pipeline_schedule로 대체합니다.

GraphQL 필드 take_ownership_pipeline_schedule이 사라집니다. 사용자가 파이프라인 일정의 소유권을 가져갈 수 있는지 여부를 결정하려면 대신 admin_pipeline_schedule 필드를 사용하세요.

</div>

heroku/builder:22 이미지가 사용되지 않음

Cloud Native Buildpack (CNB) 빌더 이미지가 자동 DevOps 빌드 프로젝트에서 heroku/builder:24로 업데이트되었습니다. 대부분의 경우 변화가 중단되지 않을 것으로 예상되지만, 일부 Auto DevOps 사용자 및 특히 Auto Build 사용자에게는 중단 변경이 될 수 있습니다. 워크로드의 영향을 더 잘 이해하기 위해 다음을 검토하세요:

• Heroku-24 stack 릴리스 노트
• Heroku-24 stack 업그레이드 노트
• Heroku 스택 패키지

이 변경으로 인해 여러분의 파이프라인에 영향을 줍니다. Auto DevOps의 Auto Build 단계에서 제공하는 auto-build-image를 사용하는 경우입니다.

</div>

GitLab Runner Helm Chart의 runnerRegistrationToken 매개변수

GitLab Runner를 쿠버네티스에 설치하기 위해 GitLab Helm Chart를 사용하는 runnerRegistrationToken 매개변수가 사용되지 않습니다.

우리는 새로운 GitLab Runner token architecture을 활용한 바인드를 실행할 runnerToken을 활용하기 위한 새로운 방법을 구현할 계획입니다. 해당 작업은 이 이픽에서 관리됩니다.

GitLab 18.0 및 이후에는 새로운 GitLab Runner token architecture에서 소개된 런너 등록 방법만 지원될 것입니다.

</div>

incoming_email 및 service_desk_email의 sidekiq 전달 방식이 사용되지 않음

incoming_email 및 service_desk_email의 sidekiq 전달 방법이 사용되지 않으며 GitLab 18.0에서 제거될 예정입니다.

GitLab은 mail_room에서 이메일을 가져오기 위해 별도의 프로세스 인 sidekiq 를 사용합니다. 현재 GitLab 관리자는 mail_room에서 GitLab으로 수신된 이메일을 전달하기 위해 sidekiq 또는 webhook 전달 방법을 구성할 수 있습니다.

사용되지 않는 sidekiq 전달 방법을 사용하면 mail_room이 작업 데이터를 GitLab Redis 대기열에 직접 작성합니다. 이는 전달 방법과 Redis 구성 사이에 강력한 결합이 있음을 의미합니다. 또 다른 단점은 작업 페이로드 압축과 같은 프레임워크 최적화가 누락된다는 것입니다.

webhook 전달 방법을 사용하면 mail_room이 수신된 이메일 바디를 GitLab API에 푸시합니다. 그러면 mail_room은 Redis 구성을 알 필요가 없고 GitLab 애플리케이션이 처리 작업을 추가합니다. mail_room은 공유 비밀 키로 인증합니다.

Omnibus 설치를 다시 구성하면이 비밀 파일의 구성 설정이 자동으로 생성되므로 비밀 파일 구성 설정이 필요하지 않습니다.

아래와 같이 실행 명령을 통해 사용자 지정 비밀 키 파일(32 문자 base 64 인코딩)을 구성할 수 있습니다. 그런 다음 incoming_email_secret_file 및 service_desk_email_secret_file에서 비밀 파일을 참조하세요(항상 절대 경로를 지정하세요):

echo $( ruby -rsecurerandom -e "puts SecureRandom.base64(32)" ) > ~/.gitlab-mailroom-secret

GitLab을 여러 대의 기계에서 실행 중이면 각 기계에 비밀 키 파일을 제공해야 합니다.

incoming_email_delivery_method 및 service_desk_email_delivery_method의 전달 방식을 sidekiq 대신 webhook 전달 방식으로 전환할 것을 권장합니다. 이러한 변경으로 이메일 수신을 간소화하고 GitLab을 더 잘 관리할 수 있는 여러 가지 개선 사항이 추가될 것으로 기대합니다.

Issue 393157에서는 일반적으로 이메일 수신을 개선하기 위한 작업을 추적합니다. 이를 통해 향후 GitLab의 인프라 구축을 간소화하고 다양한 개선 사항이 이루어질 것으로 기대합니다.

</div>

workflow:rules 템플릿

workflow:rules 템플릿은 중지 예정이며 더 이상 사용을 권장하지 않습니다. 이러한 템플릿을 사용하면 파이프라인의 유연성이 크게 제한되고 새로운 workflow 기능을 사용하기가 어려워집니다.

이는 CI/CD 구성요소를 선호하여 CI/CD 템플릿을 사용하지 않는 작은 한 걸음입니다. 대체품을 찾거나 파이프라인에 명시적으로 workflow:rules를 추가할 수 있습니다.

</div> </div>

Geo: Legacy replication details routes for designs and projects deprecated

레거시 데이터 유형을 Geo self-service framework로 이관하는 일환으로 다음과 같은 복제 세부 정보 라우트가 폐기되었습니다:

• Designs /admin/geo/replication/designs가 /admin/geo/sites/<Geo Node/Site ID>/replication/design_management_repositories로 대체됨
• Projects /admin/geo/replication/projects가 /admin/geo/sites/<Geo Node/Site ID>/replication/projects로 대체됨

GitLab 16.4부터 17.0까지 레거시 라우트 조회는 자동으로 새 라우트로 리디렉션됩니다. 17.0에서 리디렉션을 제거할 것입니다. 레거시 라우트를 사용하는 즐겨찾기 또는 스크립트를 업데이트해 주십시오.

</div>