Enterprise Server 3.8 release notes

On an instance with GitHub Actions enabled, a workflow job for GitHub Actions would not start if a matching runner group was unavailable when the job was initially queued, even if a matching runner group became available after the job entered the queue.

On an instance with GitHub Actions enabled, GitHub Actions will now properly execute after restoration of a deleted repository.

On an instance with GitHub Actions enabled, nested calls to reusable workflows within a reusable workflow job with a matrix correctly evaluate contexts within expressions, like strategy: ${{ inputs.strategies }}.

In some cases, graphs on the Management Console's monitor dashboard failed to render.

After an administrator used the /setup/api/start REST API endpoint to upload a license, the configuration run failed with a Connection refused error during the migrations phase.

On an instance in a cluster configuration, when a site administrator set maintenance mode using ghe-maintenance -s, a Permission denied error appeared when the utility tried to access /data/user/common/cluster.conf.

On an instance in a high availability configuration, if an administrator tore down replication from a replica node using ghe-repl-teardown immediately after running ghe-repl-setup, but before ghe-repl-start, an error indicated that the script cannot launch /usr/local/bin/ghe-single-config-apply - run is locked. ghe-repl-teardown now displays an informational alert and continues the teardown.

During configuration of high availability, if a site administrator interrupted the ghe-repl-start utility, the utility erroneously reported that replication was configured, and the instance would not perform expected clean-up operations.

Commands that site administrators ran via SSH on any of the instances nodes were not logged in /var/log/ssh-console-audit.log.

On instances configured to use the private beta of SCIM for GitHub Enterprise Server, users' authentication with SSH keys and personal access tokens failed due to an erroneous requirement for authorization.

After a user imported a repository with push protection enabled, the repository was not immediately visible in the security overview's "Security Coverage" view.

Responses from the /repositories REST API endpoint erroneously included deleted repositories.

When a site administrator used ghe-migrator to migrate data to GitHub Enterprise Server, in some cases, nested team relationships would not persist after teams were imported.

If a repository contained a CODEOWNERS file with check annotations, pull requests "Files changed" tab returned a 500 error and displayed "Oops, something went wrong" in the "Unchanged files with check annotations" section.

On an instance with GitHub Actions enabled, if a user manually triggered a workflow using the REST API but did not specify values for optional booleans, the API failed to validate the request and returned a 422 error.

When users searched for gists, the text in the search field was not visible in some cases because the texts color was identical to the color of the fields background.

In some cases on an instance with multiple nodes, GitHub Enterprise Server erroneously stopped writing to replica fileservers, causing repository data to fall out of sync.

On an instance with GitHub Connect enabled, if "Users can search GitHub.com" was enabled, users would not see issues in private and internal repositories in search results for GitHub.com.

When a site administrator configures an outbound web proxy server for GitHub Enterprise Server, the instance now validates top-level domains (TLDs) excluded from the proxy configuration. By default, you can exclude public TLDs that the IANA specifies. Site administrators can specify a list of unregistered TLDs to exclude using ghe-config. The . prefix is required for any public TLDs. For example, .example.com is valid, but example.com is invalid. For more information, see "아웃바운드 웹 프록시 서버 구성."

To avoid intermittent issues with the success of Git operations on an instance with multiple nodes, GitHub Enterprise Server checks the status of the MySQL container before attempting a SQL query. The timeout duration has also been reduced.

The default path for output from ghe-saml-mapping-csv -d is /data/user/tmp instead of /tmp. For more information, see "명령줄 유틸리티."

On an instance with a GitHub Advanced Security license, users who author custom patterns for secret scanning can provide expressions that must or must not match that are up to 2,000 characters. This limit is an increase from 1,000 characters.

이제 GitHub Enterprise Server에서 작업을 계획하고 추적하기 위한 유연한 도구인 프로젝트를 베타로 사용할 수 있습니다. 프로젝트는 사용자가 작업을 효과적으로 계획하고 추적하는 데 도움이 되는 문제 및 끌어오기 요청을 통합하는 적응 가능한 스프레드시트입니다. 사용자는 여러 보기를 만들고 사용자 지정할 수 있으며 각 보기는 문제와 끌어오기 요청을 필터링, 정렬 및 그룹화할 수 있습니다. 또한 사용자는 사용자 지정 필드를 정의하여 팀 또는 프로젝트에 대한 고유한 메타데이터를 추적하여 모든 요구 사항 또는 프로세스에 대한 사용자 지정을 허용할 수 있습니다. 이 기능은 변경될 수 있습니다. 자세한 내용은 "Projects (beta) 정보"을 참조하세요.

사이트 관리자는 관리 콘솔에 대한 전용 사용자 계정을 만들어 인스턴스의 보안을 향상시킬 수 있습니다. 루트 사이트 관리자만 사용자 계정을 만들 수 있습니다. 사용자 계정에 대한 액세스를 제어하려면 편집기 또는 운영자 역할을 할당합니다. 운영자는 인스턴스에 대한 관리 SSH 액세스를 관리할 수 있습니다. 자세한 내용은 "관리 콘솔에 대한 액세스 관리"를 참조하세요.

내부 정책을 설정하거나 준수하기 위해 사이트 관리자는 관리 콘솔을 사용하여 GitHub Actions 생성된 검사 데이터 및 상태 API를 포함하여 검사와 관련된 데이터의 보존을 위한 인스턴스 정책을 구성할 수 있습니다. 관리자는 보존을 사용하거나 사용하지 않도록 설정하거나, 사용자 지정 보존 임계값을 설정하거나, 사용자 지정 하드 삭제 임계값을 설정할 수 있습니다. 자세한 내용은 "애플리케이션 구성" [업데이트됨: 2023-03-02]을 참조하세요.

명령줄 유틸리티를 사용하여 ghe-support-bundle 지원 번들을 생성할 때 사이트 관리자는 번들의 데이터 수집에 사용할 정확한 기간을 지정할 수 있습니다. 자세한 내용은 “명령줄 유틸리티”를 참조하세요.

사용자는 GitHub Enterprise Server 인스턴스에 대한 브라우저 및 GitHub Mobile 세션을 모두 검토하고 취소할 수 있습니다. 자세한 내용은 "세션 보기 및 관리"를 참조하세요.

엔터프라이즈 소유자는 리포지토리 관리자가 Dependabot 경고를 사용하거나 사용하지 않도록 설정할 수 있는지 여부를 구성할 수 있습니다. GitHub Advanced Security 라이선스가 있는 인스턴스에서 엔터프라이즈 소유자는 리포지토리 관리자가 GitHub Advanced Security 기능 또는 비밀 검사를 사용하도록 설정할 수 있는지 여부를 제어하는 정책을 설정할 수도 있습니다. 자세한 내용은 "엔터프라이즈에 대한 코드 보안 및 분석에 대한 정책 적용"을 참조하세요.

엔터프라이즈 및 조직 소유자는 전체 관리 권한을 제공하지 않고 감사 로그 엔드포인트에 대한 액세스 권한을 부여하여 최소 권한 원칙 준수를 지원할 수 있습니다. 이 액세스를 제공하기 위해 개인용 액세스 토큰 및 OAuth 앱은 이제 범위를 지원합니다 read:audit_log . 자세한 내용은 “엔터프라이즈에 감사 로그 API 사용”을 참조하세요.

엔터프라이즈 소유자는 감사 로그 이벤트에서 토큰 데이터를 확인하여 인증 토큰과 관련된 작업을 보다 쉽게 검색하고 추적할 수 있습니다. 자세한 내용은 "액세스 토큰에서 수행하는 감사 로그 이벤트 식별"을 참조하세요.

엔터프라이즈 소유자는 Datadog 엔드포인트에 대한 감사 로그 스트리밍을 구성할 수 있습니다. 자세한 내용은 “엔터프라이즈의 감사 로그 스트림”을 참조하세요.

GitHub Advanced Security 라이선스가 있는 인스턴스의 엔터프라이즈 소유자는 감사 로그에서 GitHub Advanced Security, 비밀 검사 및 푸시 보호 사용 설정에 대한 변경 내용을 볼 수 있습니다. 조직 소유자는 감사 로그에서 푸시 보호를 위해 사용자 지정 메시지의 변경 내용을 볼 수 있습니다. 자세한 내용은 다음 설명서를 참조하세요.

• "엔터프라이즈에 대한 감사 로그 이벤트"의 "business_secret_scanning범주 작업business_secret_scanning_push_protection", "범주 작업" 및 "business_secret_scanning_push_protection_custom_message범주 작업"
• “조직의 감사 로그 검토”

GitHub Advanced Security 라이선스가 있는 인스턴스의 엔터프라이즈 소유자는 REST API를 사용하여 규정 준수를 보장하고 비밀 검사 및 푸시 보호의 롤아웃을 인스턴스의 모든 조직에 간소화할 수 있습니다. 이 엔드포인트는 리포지토리 및 조직의 엔드포인트뿐만 아니라 기존 웹 UI를 보완합니다. 자세한 내용은 REST API 설명서의 "코드 보안 및 분석"을 참조하세요.

GitHub Advanced Security 라이선스가 있는 인스턴스에서 비밀 검사를 사용하는 엔터프라이즈 및 조직 소유자는 REST API를 사용하여 푸시 보호가 비밀을 포함하는 푸시를 차단할 때 표시할 사용자 지정 링크를 지정할 수 있습니다. 자세한 내용은 REST API 설명서의 "코드 보안 및 분석" 또는 "조직"을 참조하세요.

비밀 검사 경고를 해제하는 GitHub Advanced Security 라이선스가 있는 인스턴스의 사용자는 웹 UI 또는 REST API를 사용하여 선택적 주석을 제공하여 다른 사용자가 해제 이유를 이해하는 데 도움이 될 수 있습니다. 자세한 내용은 다음 설명서를 참조하세요.

• "비밀 검사에서 경고 관리"
• REST API 설명서의 "비밀 검사"

GitHub Advanced Security 라이선스가 있는 인스턴스의 사용자는 리포지토리 또는 조직 수준에서 경고 심각도에 따라 코드 검사 API의 결과를 필터링할 수 있습니다. 매개 변수를 severity 사용하여 특정 심각도의 코드 검사 경고만 반환합니다. 자세한 내용은 REST API 설명서의 "코드 검사"를 참조하세요.

GitHub Advanced Security 라이선스가 있는 인스턴스의 사용자는 CodeQL 코드 검사를 사용하여 취약성 및 오류에 대한 두 가지 추가 언어를 분석할 수 있습니다. Ruby에 대한 지원은 일반적으로 제공되며 Kotlin에 대한 지원은 베타 버전이며 변경될 수 있습니다.

• Ruby 분석은 베타 중에 감지할 수 있는 CWU(일반적인 약점) 수의 두 배 이상을 검색할 수 있습니다. 총 30개의 규칙은 XSS(교차 사이트 스크립팅), 정규식 ReDoS(서비스 거부), SQL 삽입 등을 포함하여 다양한 취약성을 식별할 수 있습니다. Ruby-on-Rails에 대한 추가 라이브러리 및 프레임워크 적용 범위는 웹 서비스 개발자가 훨씬 더 정확한 결과를 얻을 수 있도록 합니다. GitHub Enterprise Server는 3.1을 포함하여 모든 일반적인 Ruby 버전을 지원합니다.
• Kotlin 지원은 기존 Java 지원의 확장이며 모바일 및 서버 쪽 애플리케이션 모두 에 적용되는 Java에 대한 기존 CodeQL 쿼리의 이점을 제공합니다. 또한 GitHub는 의도 처리, Webview 유효성 검사 문제, 조각 삽입 등의 문제를 다루는 다양한 모바일 관련 쿼리를 개선하고 추가했습니다.

코드 검사에 대한 자세한 내용은 "CodeQL을 사용하여 코드 검사 정보"를 참조하세요.

CodeQL 코드 검사를 사용하는 GitHub Advanced Security 라이선스가 있는 인스턴스의 사용자는 GitHub Actions 워크플로 파일 내에서 Go 분석에 대한 빌드 구성을 사용자 지정할 수 있습니다. Go 분석을 위한 기존 CodeQL 워크플로에는 변경이 필요하지 않으며 계속 지원됩니다. 자세한 내용은 "컴파일된 언어에 대한 CodeQL 워크플로 구성"을 참조하세요.

코드 보안을 개선하고 취약한 종속성을 업데이트하는 프로세스를 간소화하기 위해 더 많은 사용자가 종속성 업데이트를 사용하여 자동 끌어오기 요청을 받을 수 있습니다.

• GitHub Actions 작성자는 워크플로 파일 내에서 종속성을 자동으로 업데이트할 수 있습니다.
• Pub를 사용하는 Dart 또는 Flutter 개발자는 프로젝트 내에서 종속성을 자동으로 업데이트할 수 있습니다.

자세한 내용은 “Dependabot 보안 업데이트 정보”를 참조하세요.

종속성 그래프가 사용하도록 설정된 인스턴스의 Dart 및 JavaScript 개발자는 프로젝트의 종속성 내에서 알려진 취약성에 대한 Dependabot 경고를 받을 수 있습니다.

• Dart의 경우 종속성 그래프는 및 pubspec.yaml 파일을 검색합니다pubspec.lock.
• Node.js 및 npm을 사용하는 JavaScript 개발자는 Yarn v2 및 v3 매니페스트 내에서 알려진 취약성에 대한 경고를 받을 수 있습니다. 이렇게 하면 v1 매니페스트에 대한 기존 지원이 보완됩니다. 종속성 그래프는 , 및 yarn.lock 파일을 검색합니다package.json.

자세한 내용은 다음 문서를 참조하세요.

• “종속성 그래프 정보”
• "GitHub 권고 데이터베이스에서 보안 권고 검색"
• "Dependabot 경고 정보"

종속성 그래프가 활성화된 인스턴스에서 지원되는 패키지 관리자를 사용하는 Python 개발자는 PEP 621 표준을 따르는 파일 내 pyproject.toml 의 종속성에 대한 Dependabot 경고를 받을 수 있습니다. 자세한 내용은 “Dependabot 버전 업데이트 정보”를 참조하세요.

Dependabot 경고를 수신하는 Python 개발자는 현재 종속성 요구 사항이 새 버전에 이미 충족된 경우 버전 업데이트 수를 줄일 수 있습니다. 이 동작을 구성하려면 버전 관리 전략을 사용합니다 increase-if-necessary . 자세한 내용은 “dependabot.yml 파일에 대한 구성 옵션”을 참조하세요.

엔터프라이즈 소유자는 REST API를 사용하여 인스턴스에 대한 Dependabot 경고를 검색할 수 있습니다. 이 엔드포인트는 베타 버전이며 변경될 수 있습니다. 자세한 내용은 REST API 설명서의 "Dependabot 경고"를 참조하세요.

조직 소유자는 REST API를 사용하여 조직에 대한 Dependabot 경고를 검색할 수 있습니다. 이 엔드포인트는 베타 버전이며 변경될 수 있습니다. 자세한 내용은 "Dependabot 경고"를 참조하세요.

사용자는 REST API를 사용하여 Dependabot 경고를 프로그래밍 방식으로 보고 작업할 수 있습니다. Dependabot 경고를 보고 나열하고 업데이트하는 새 엔드포인트는 베타로 제공됩니다. 이러한 엔드포인트는 변경될 수 있습니다. 자세한 내용은 REST API 설명서의 "Dependabot 경고"를 참조하세요.

보안 태세에 대한 가시성을 높이고 위험 분석을 개선하기 위해 사용자는 보안 개요 내에서 적용 범위 및 위험 보기에 액세스할 수 있습니다. 적용 범위 보기는 리포지토리 전체의 사용을 보여 주지만 위험 보기는 리포지토리 전체에서 경고를 표시합니다. GitHub Advanced Security 라이선스가 있는 인스턴스의 조직 소유자, 보안 관리자 및 리포지토리 관리자는 보안 개요의 적용 범위 보기에서 보안 기능을 사용하도록 설정할 수 있습니다. 보기는 "개요" 페이지를 대체하며 퍼블릭 베타 버전이며 변경될 수 있습니다. 자세한 내용은 “보안 개요 정보”를 참조하세요.

기여자는 파일을 만들어 리포지토리의 보안 정책을 정의할 수 있습니다 SECURITY.md . 정책의 가시성을 높이기 위해 GitHub Enterprise Server는 리포지토리의 코드 탭에서 정책에 연결합니다. 자세한 내용은 "리포지토리에 보안 정책 추가"를 참조하세요.

종속성 검토 API는 일반적으로 사용할 수 있으며, 이제 연결된 GitHub 작업을 통해 사용자가 로컬 또는 외부 구성 파일을 참조할 수 있습니다. 자세한 내용은 다음 설명서를 참조하세요.

• REST API 설명서의 "종속성 검토"
• "종속성 검토 구성"

GraphQL API는 리포지토리의 종속성 그래프에 대한 액세스를 제공합니다. 이 기능은 미리 보기 상태이며 변경될 수 있습니다. 자세한 내용은 GraphQL API 설명서의 "개체"를 참조하세요.

GitHub Actions 스토리지를 구성하는 동안 사이트 관리자는 OIDC를 사용하여 개체 스토리지 공급자에 연결하여 중요한 비밀 및 액세스 키 입력과 관련된 위험을 방지할 수 있습니다. GitHub Enterprise Server의 GitHub Actions AWS, Azure 및 Google Cloud Platform에 연결하기 위한 OIDC를 지원합니다. 이 기능은 베타 버전이며 변경될 수 있습니다. 자세한 내용은 "GitHub Enterprise Server에 GitHub Actions 사용"을 참조하세요.

및 set-output 워크플로 명령에서 신뢰할 수 없는 데이터 로깅을 set-state 방지하기 위해 작업 작성자는 환경 파일을 사용하여 상태 및 출력을 관리할 수 있습니다.

• 이 기능을 사용하려면 실행기 애플리케이션이 버전 2.297.0 이상이어야 합니다. 버전 2.298.2 이상에서는 또는 set-output 명령을 사용하는 save-state 사용자에게 경고합니다. 이러한 명령은 향후 릴리스에서 완전히 사용하지 않도록 설정됩니다.
• 업데이트 saveState 된 함수와 setOutput 함수를 사용하려면 GitHub Actions 도구 키트를 사용하는 워크플로에서 v1.10.0 이상을 호출 @actions/core 해야 합니다.

자세한 내용은 "GitHub Actions 워크플로 명령"을 참조하세요.

프라이빗 리포지토리에서 작업 및 재사용 가능한 워크플로를 공유하는 기능은 일반적으로 사용할 수 있습니다. 사용자는 프라이빗 리포지토리의 워크플로를 동일한 조직 또는 사용자 계정이 소유하는 다른 프라이빗 리포지토리 또는 인스턴스의 모든 프라이빗 리포지토리와 공유할 수 있습니다. 자세한 내용은 다음 설명서를 참조하세요.

• "리포지토리에 대한 GitHub Actions 설정 관리"
• REST API 설명서의 "GitHub Actions 권한"

사용자는 리포지토리 또는 조직의 워크플로에서 재사용할 수 있는 구성 변수를 정의하여 워크플로 가독성을 개선하고 중요하지 않은 구성 데이터를 암호화된 비밀로 저장할 필요가 없습니다. 이 기능은 베타 버전이며 변경될 수 있습니다. 자세한 내용은 "변수"를 참조하세요.

사용자는 워크플로 실행 이름을 동적으로 지정할 수 있습니다. run-name 는 식을 수락하고 동적 이름은 워크플로 실행 목록에 표시됩니다. 자세한 내용은 “GitHub Actions의 워크플로 구문”을 참조하세요.

사용자는 키 내 runs-on 의 워크플로에 대해 의도한 실행기 그룹의 이름을 정의하여 의도한 그룹 외부의 실행기에서 작업이 실행되지 않도록 방지할 수 있습니다.

runs-on:
  group: my-group
  labels: [ self-hosted, label-1 ]

또한 GitHub Enterprise Server는 더 이상 조직 및 엔터프라이즈 수준에서 이름이 동일한 실행기 그룹을 만들 수 없습니다. 엔터프라이즈의 실행기 그룹과 이름을 공유하는 조직 내의 모든 실행기 그룹에 대해 경고 배너가 표시됩니다.

사용자는 필요한 워크플로를 정의하여 조직의 모든 리포지토리에서 표준 CI/CD 사례를 적용할 수 있습니다. 이러한 워크플로는 검사가 통과될 때까지 병합을 차단하는 리포지토리의 기본 분기를 대상으로 하는 모든 끌어오기 요청에 대해 필요한 상태 검사로 트리거됩니다. 이 기능은 베타 버전이며 변경될 수 있습니다. 자세한 내용은 "필수 워크플로"를 참조하세요.

클라우드 배포 워크플로에서 OIDC 구성의 표준화를 사용하도록 설정하기 위해 조직 소유자 및 리포지토리 관리자는 사용자 지정 템플릿을 정의하여 OIDC 토큰 내에서 클레임 형식을 구성할 subject 수 있습니다. 자세한 내용은 “OpenID Connect 보안 강화 정보”를 참조하세요.

리포지토리 내의 캐시 사용을 보다 투명하게 제어할 수 있도록 종속성 및 기타 재사용된 파일을 actions/cache 캐시하는 사용자는 인스턴스의 웹 UI에서 캐시를 관리할 수 있습니다. 자세한 내용은 “워크플로 속도를 높이기 위한 종속성 캐싱”을 참조하세요.

사용자는 프로필 내에 현지 표준 시간대를 표시하여 가용성에 대한 기대치를 설정할 수 있습니다. 사용자의 프로필 또는 호버카드를 보는 사람 표준 시간대와 사용자의 현지 시간 뒤 또는 앞의 시간을 볼 수 있습니다. 자세한 내용은 “프로필 개인 설정”을 참조하세요.

검색 가능성을 개선하기 위해 GitHub 토론은 다음과 같은 향상된 기능을 제공합니다.

• 리포지토리 소유자는 토론을 특정 범주에 고정할 수 있습니다.
• 범주 제목 및 설명은 범주의 페이지에 표시됩니다.

조직 구성원이 리포지토리를 포크하는 방법을 관리하기 위해 조직 소유자는 모든 조직에 대한 전용 포크 정책을 설정할 수 있습니다. 이 정책은 엔터프라이즈에 대해 설정된 포크 정책보다 엄격해야 합니다. 자세한 내용은 “조직의 포크 정책 관리”를 참조하세요.

조직 소유자는 외부 협력자가 GitHub 및 OAuth 앱의 설치를 요청하지 않도록 하여 조직 보안을 향상시킬 수 있습니다. 자세한 내용은 "OAuth 앱 및 GitHub 앱 액세스 요청 제한"을 참조하세요.

불필요한 경우 리포지토리에 대한 전체 관리 액세스 권한을 제공하지 않도록 리포지토리 관리자는 사용자가 분기 보호를 무시할 수 있는 사용자 지정 역할을 만들 수 있습니다. 관리자가 관리자 액세스 또는 바이패스 권한이 있는 모든 사용자에게 분기 보호를 적용하려면 관리자가 위의 설정을 무시하지 않도록 허용 안 을 사용하도록 설정할 수 있습니다. 자세한 내용은 "조직의 사용자 지정 리포지토리 역할 관리" 및 "보호된 분기 정보"를 참조하세요.

리포지토리 관리자는 마지막 푸셔가 아닌 다른 사용자가 끌어오기 요청 승인을 요구하거나 분기를 잠그면 분기의 보안 및 안정성을 보장할 수 있습니다. 자세한 내용은 “보호된 분기 정보”를 참조하세요.

워크플로가 실행되기 전에 누군가가 GitHub Actions 워크플로 내에서 코드를 검토해야 하는 시나리오에서 리포지토리 관리자는 프라이빗 포크에서 워크플로 실행을 트리거하기 전에 리포지토리에 대한 쓰기 권한이 있는 사용자의 승인을 요구할 수 있습니다. 자세한 내용은 "리포지토리에 대한 GitHub Actions 설정 관리"를 참조하세요.

GraphQL API는 분기와 문제 간의 링크 만들기 및 제거를 지원합니다. 자세한 내용은 다음 설명서를 참조하세요.

• "문제 해결을 위한 분기 만들기"
• "변형" GraphQL API 설명서의 "createLinkedBranch" 및 "deleteLinkedBranch"
• GraphQL API 설명서의 "개체"

계정과 연결된 여러 전자 메일 주소를 가진 사용자는 squash 병합으로 만든 Git 커밋이 올바른 전자 메일 주소와 연결되어 있는지 더 잘 확인할 수 있습니다. 끌어오기 요청을 병합하면 드롭다운 메뉴가 표시되어 사용자가 커밋의 작성자로 사용할 전자 메일 주소를 선택할 수 있습니다.

사용자는 웹 UI, REST API 또는 GraphQL API를 사용하여 리포지토리 내의 특정 릴리스를 최신 릴리스로 표시할 수 있습니다. 자세한 내용은 다음 설명서를 참조하세요.

• “리포지토리에서 릴리스 관리”
• REST API 설명서의 "릴리스"
• GraphQL API 설명서의 "개체"

사용자는 Slack 또는 Microsoft Teams 내에서 직접 GitHub Enterprise Server 활동에 대한 실시간 업데이트를 받고 작업하여 시간을 절약하고 컨텍스트를 덜 자주 전환할 수 있습니다. 이러한 서비스에 대한 GitHub의 통합이 이제 일반 공급됩니다. 자세한 내용은 "GitHub 확장 및 통합"을 참조하세요.

사이트 관리자가 관리 SSH 액세스를 사용하여 명령을 실행하면 이제 명령이 기록됩니다. GitHub 지원 문제 해결 및 디버그를 지원하기 위해 지원 번들에는 이러한 명령이 포함된 로그가 포함됩니다.

엔터프라이즈, 조직 또는 사용자 감사 로그 내에서 이벤트 검색을 간소화하기 위해 이제 검색 창에 사용 가능한 필터 목록이 표시됩니다.

사이트 관리자가 GitHub Enterprise Importer CLI, startRepositoryMigration GraphQL API 또는 조직 마이그레이션 시작 REST API를 사용하여 GitHub Enterprise Server에서 마이그레이션하려면 먼저 관리자가 관리 콘솔을 사용하여 마이그레이션 보관 파일 스토리지에 대한 Blob Storage 공급자를 구성해야 합니다. 지원되는 제공에는 Amazon S3 및 Azure Blob Storage 포함되어 있습니다. 이전에는 Blob Storage가 필요하지 않았으며 필요에 따라 를 사용하여 gh gei구성할 수 있었습니다. 이 변경으로 Git 원본 또는 메타데이터가 1GB보다 큰 마이그레이션에 대한 지원이 추가됩니다.

GitHub Advanced Security 라이선스가 있는 인스턴스의 사용자가 검색된 비밀을 더 잘 이해하고 조치를 취할 수 있도록 타사 API 키와 관련된 비밀 검사 경고에는 이제 공급자 설명서에 대한 링크가 포함됩니다. 자세한 내용은 “비밀 검사 정보”를 참조하세요.

이제 GitHub Advanced Security 라이선스가 있는 인스턴스의 사용자는 참가자가 비밀에 대한 푸시 보호를 우회한 경우를 포함하여 경고의 타임라인 내에서 직접 비밀 검사 경고에 대해 수행한 작업을 볼 수 있습니다.

GitHub Advanced Security 라이선스가 있는 인스턴스는 기록 검사를 정기적으로 실행하여 GitHub Advanced Security 및 비밀 검사를 사용하도록 설정된 리포지토리에서 새로 추가된 비밀 유형을 검색합니다. 이전에는 사용자가 기록 검사를 수동으로 실행해야 했습니다.

GitHub Advanced Security 라이선스가 있는 인스턴스에서 향후 GitHub Enterprise Server 릴리스에서 API 또는 웹 UI에서 검색된 비밀의 미리 보기를 항상 표시할 수 있도록 검색된 비밀은 이제 소스 코드와 별도로 저장됩니다. 검색된 비밀은 대칭 암호화를 사용하여 저장됩니다. [업데이트: 2023-02-15]

Dependabot 업데이트에 프라이빗 레지스트리를 사용하는 경우 GitHub Enterprise Server는 보다 안전하게 작동합니다. 다음 에코시스템에 대해 프라이빗 레지스트리가 구성된 경우 인스턴스는 더 이상 퍼블릭 레지스트리에 대한 패키지 요청을 수행하지 않습니다.

• 번들러
• Docker
• Gradle
• Maven
• npm
• Nuget
• Python
• Yarn

자세한 내용은 “dependabot.yml 파일에 대한 구성 옵션”을 참조하세요.

자체 호스팅 Hex 리포지토리를 사용하는 Elixir 개발자는 GitHub Enterprise Server에서 Dependabot 버전 업데이트에 대한 프라이빗 레지스트리를 구성할 수 있습니다. 자세한 내용은 “dependabot.yml 파일에 대한 구성 옵션”을 참조하세요.

Dependabot 경고는 다음과 같은 유용성 향상 기능을 제공합니다.

• Dependabot이 업데이트에 대한 끌어오기 요청을 만들려고 시도하면 경고 페이지가 자동으로 새로 고쳐집니다.
• 경고는 Dependabot 업데이트의 끌어오기 요청에 보다 정확하게 매핑됩니다.
• 커뮤니티에 대한 경고를 개선하기 위해 사용자는 GitHub Advisory Database에서 직접 경고 개선 사항을 제안할 수 있습니다.

사용자는 를 보다 쉽게 언급 @dependabot할 수 있습니다. 사용자를 언급할 때 Dependabot 사용자 계정이 이제 자동 완성 제안으로 표시됩니다.

취약한 종속성이 있는 리포지토리에서 Dependabot은 더 이상 노란색 배너를 표시하지 않습니다. 기여자에게 취약한 종속성을 알리기 위해 보안 탭에 경고 카운터가 표시됩니다.

사용자가 에서 기존 Dependabot 구성 dependabot.yml을 사용하여 리포지토리를 포크하는 경우 기본적으로 포크에서 Dependabot 업데이트가 비활성화됩니다. 포크에서 업데이트를 사용하도록 설정하려면 사용자가 리포지토리의 코드 보안 및 분석 설정을 방문해야 합니다. 자세한 내용은 "Dependabot 버전 업데이트 구성"을 참조하세요.

Dependabot 경고에 대한 웹후크를 받으려는 통합자는 새 dependabot_alert 웹후크를 사용해야 합니다. 이 웹후크는 웹후크를 대체합니다 repository_vulnerability_alert . 자세한 내용은 “웹후크 이벤트 및 페이로드”를 참조하세요.

SHA 커밋으로 다른 작업을 참조하는 GitHub Actions 워크플로의 가독성을 향상시키기 위해 작업 작성자는 종종 작업을 호출하는 줄에 해당 의미 체계 버전을 포함한 주석을 작성합니다. 시간을 절약하기 위해 Dependabot 버전 업데이트에 대한 끌어오기 요청은 이제 이러한 주석에서 의미 체계 버전을 자동으로 업데이트합니다.

Node.js, npm 및 Dependabot 보안 업데이트를 사용하는 JavaScript 개발자는 전이적 종속성으로 npm 프로젝트를 업데이트할 때 시간을 절약할 수 있습니다.

• Dependabot은 부모 및 자식 종속성을 함께 업데이트할 수 있습니다. 이전에는 부모가 호환되지 않는 특정 버전 범위가 필요하고 수동 업그레이드가 필요한 경우 Dependabot은 전이적 종속성을 업데이트하지 않았습니다.
• Dependabot은 직접 종속성에 대한 업데이트가 트리에서 취약한 전이적 종속성을 제거하는 경고를 해결하는 끌어오기 요청을 만들 수 있습니다.

자세한 내용은 “Dependabot 보안 업데이트 정보”를 참조하세요.

Docker 에코시스템의 버전 업데이트에 Dependabot을 사용하는 사용자를 위해 Dependabot은 Kubernetes 매니페스트에서 Docker 이미지 태그를 사전에 업데이트합니다. 자세한 내용은 "Dependabot 버전 업데이트 구성" 및 "dependabot.yml 파일에 대한 구성 옵션"을 참조하세요.

다음과 같은 변경 내용을 포함하여 GitHub.com 보안 권고에 기여하는 사용자가 다양한 개선 사항을 사용할 수 있습니다.

• 더 빠른 검토를 위해 GitHub는 사용자에게 변경 이유를 추가하라는 메시지를 표시합니다.
• 기여가 사용자의 의도와 일치하도록 하기 위해 GitHub는 diff에서 참조 링크의 순서를 다시 지정하지 않습니다.

GitHub Actions 다음과 같은 검색 기능 및 접근성 향상 기능을 제공합니다.

• 워크플로 및 워크플로 실행을 검색하기 위한 탐색 환경이 개선되었습니다.
• 추가된 구조는 호출자와 재사용 가능한 워크플로 간의 계층 구조를 더 잘 나타냅니다.
• 모바일 검색 환경은 더 일관되며 여러 뷰포트 크기를 지원합니다.

GitHub Actions 워크플로는 및 이벤트와 repository_dispatch 함께 workflow_dispatch 사용할 GITHUB_TOKEN 때 더 이상 끝없이 트리거되지 않습니다. 이 변경 이전에는 에 의해 GITHUB_TOKEN 트리거된 이벤트가 새 워크플로 실행을 만들지 않았습니다. 자세한 내용은 “워크플로 트리거”를 참조하세요.

GitHub Actions 워크플로의 예약된 실행의 경우 사용자는 에 대한 페이로드 내에서 리포지토리, 조직 및 엔터프라이즈에 대한 github.event추가 정보를 볼 수 있습니다.

GitHub Actions 사용자는 환경 보호 규칙을 사용할 때 작업의 진행 상황을 더 잘 파악할 수 있습니다. workflow_job 웹후크는 작업에서 환경 보호 규칙을 대기할 때마다 새 waiting 상태를 지원합니다. 또한 작업이 YAML 정의 workflow_job 의 키를 참조하는 environment 경우 웹후크 페이로드에는 새 속성deployment도 포함됩니다. deployment 에는 검사 실행이 만든 배포에 대한 메타데이터가 포함되어 있습니다. 자세한 내용은 “배포에 환경 사용”을 참조하세요.

조직 소유자는 감사 로그 이벤트 내에서 더 의미 있는 컨텍스트를 찾을 수 있습니다.

• business.sso_response 및 org.sso_response 이벤트는 감사 로그 스트리밍을 위한 REST API 및 페이로드에 표시됩니다.
• repo.rename, project.rename및 protected_branch.update_name 이벤트에는 필드 내에서 old_name 이름이 변경된 이들의 현재 및 과거 이름이 포함됩니다.
• Dependabot 경고에 대한 이벤트에는 경고에 대한 링크 및 정확한 타임스탬프 외에도 , ghsa_id, dismiss_reason및 dismiss_comment 필드가 포함alert_number됩니다.

사용자는 조직의 프로필에서 조직의 모든 팔로워가 포함된 목록을 볼 수 있습니다.

이제 웹 UI의 보관된 리포지토리 위에 표시되는 배너에 리포지토리의 보관 날짜가 포함됩니다.

이제 지연된 구문 강조 표시로 인해 끌어오기 요청의 대화 및 파일 탭이 더 빠르게 로드됩니다.

웹 UI와 사용자의 워크스테이션 간에 보다 일관된 환경을 제공하고 사용자가 끌어오기 요청을 자동으로 병합할 수 있는지 여부를 확인하는 프로세스를 가속화하기 위해 이제 GitHub Enterprise Server에서 전략을 사용합니다 merge-ort . 자세한 내용은 Git 설명서의 병합 전략을 참조하세요.

하나의 커밋이 포함된 끌어오기 요청의 초기 주석 표시를 개선하기 위해 이제 GitHub Enterprise Server는 GitHub의 Markdown 규칙을 준수하도록 자세한 커밋 메시지를 자동으로 다시 포맷합니다.

끌어오기 요청을 squash-병합할 때 병합하기 전에 Git 커밋의 작성자가 표시됩니다. 이전에는 병합 커밋과 병합할 때만 커밋 작성자가 표시되었습니다.

사용자가 없는 GitHub Enterprise Server 인스턴스를 새로 설정한 경우 공격자가 첫 번째 관리자 사용자를 만들 수 있습니다.

업그레이드 프로세스 중에 사용자 지정 방화벽 규칙이 제거됩니다.

웹 인터페이스를 통해 업로드된 Git LFS 추적 파일이 리포지토리에 직접 잘못 추가됩니다.

Blob의 파일 경로가 255자보다 긴 동일한 리포지토리의 Blob에 대한 퍼마링크가 포함된 경우 문제를 닫을 수 없습니다.

GitHub Connect에서 "사용자가 GitHub.com 검색할 수 있습니다"를 사용하도록 설정하면 프라이빗 및 내부 리포지토리의 문제가 GitHub.com 검색 결과에 포함되지 않습니다.

GitHub Packages npm 레지스트리는 더 이상 메타데이터 응답에서 시간 값을 반환하지 않습니다. 이 작업은 상당한 성능 향상을 허용하기 위해 수행되었습니다. 메타데이터 응답의 일부로 시간 값을 반환하는 데 필요한 모든 데이터를 계속 사용하고, 기존 성능 문제를 해결하면 나중에 이 값 반환을 다시 시작합니다.

사전 수신 후크 처리와 관련된 리소스 제한으로 인해 일부 사전 수신 후크가 실패할 수 있습니다.

다른 호스트에서 수행된 백업에서 인스턴스를 복원한 후 작업 서비스를 다시 시작해야 합니다.

리포지토리의 설정에서 읽기 권한이 있는 사용자가 토론을 만들 수 있도록 허용하는 옵션을 사용하도록 설정해도 이 기능을 사용할 수 없습니다.

구성 실행 No such object 의 유효성 검사 단계에서 Notebook 및 Viewscreen 서비스에 오류가 발생할 수 있습니다. 서비스가 여전히 올바르게 시작되어야 함에 따라 이 오류를 무시할 수 있습니다.

경우에 따라 문제를 토론으로 변환하는 동안 변환 프로세스가 중단되었을 수 있습니다. 이 경우 엔터프라이즈 소유자는 다음 문제 해결 단계를 시도하여 문제를 해결할 수 있습니다.

1. 중단된 토론 URL의 끝에서 토론의 번호를 기록해 둡니다.
2. 웹 UI에서 변환이 중단된 리포지토리로 이동합니다.
3. 웹 UI의 오른쪽 위 모서리에서 을 클릭합니다.
4. "공동 작업"에서 NUMBER 토론을 클릭합니다.
5. 목록에서 1단계의 번호를 클릭합니다.
6. "변환"에서 큐에 넣기 변환 작업을 클릭합니다.
7. 몇 분 정도 기다린 다음, 문제의 상태를 확인합니다.

변환이 아직 완료되지 않은 경우 GitHub 엔터프라이즈 지원에 문의 하세요.

로그인 시도 실패 후 루트 사이트 관리자가 관리 콘솔에서 잠기면 정의된 잠금 시간 후에 계정이 자동으로 잠금 해제되지 않습니다. 인스턴스에 대한 관리 SSH 액세스 권한이 있는 사용자는 관리 셸을 사용하여 계정의 잠금을 해제해야 합니다. 자세한 내용은 "관리 콘솔에 대한 액세스 문제 해결"을 참조하세요. [업데이트됨: 2023-02-23]

클러스터에서 GitHub Enterprise Server 3.8.0으로 업그레이드하는 동안 주 MySQL 노드 이외의 노드를 업그레이드한 후 주 MySQL 노드를 업그레이드하기 전에 를 실행 ghe-cluster-config-apply한 후 다음 오류가 여러 번 나타날 수 있습니다.

Error response from daemon: conflict: unable to delete IMAGE_ID (cannot be forced) - image is being used by running container CONTAINER_ID

GitHub는 이 문제가 해결될 때까지 클러스터 업그레이드를 기다리는 것이 좋습니다. 자세한 내용은 GitHub Enterprise Server에 대한 향후 업데이트에 대한 릴리스 정보에서 확인할 수 있습니다.