GitHub 도구 통합을 내 도구 체인에 추가하려고 시도했습니다. 도구 통합이 왜 추가되지 않습니까?

IBM Cloud에 사용자의 GitHub 계정에 액세스할 수 있는 권한이 부여되도록 사용자에게 GitHub에 대한 권한이 부여되어야 합니다.

GitHub 도구 통합이 도구 체인에 추가되지 않았습니다. Terraform 또는 API를 사용하여 GitHub 도구 통합을 작성하는 경우 User is not authorized with https://api.github.com 오류 메시지와 함께 시도가 실패합니다.

IBM Cloud에 GitHub 계정에 액세스할 권한이 없는 경우 도구 통합이 도구 체인에 추가되지 않습니다.

도구 체인을 만드는 동안 콘솔을 사용하여 GitHub 도구 연동을 구성하는 경우 다음 단계에 따라 GitHub::

1. 구성 가능한 통합 섹션에서 GitHub를 클릭하십시오.

2. 공개 IBM Cloud 도구 체인을 만들고 IBM Cloud 액세스 권한이 없는 경우 GitHub, Github에 액세스하는 데 사용할 인증 방법을 선택합니다.

   • OAuth 를 선택하는 경우 권한 부여 를 클릭하여 GitHub 웹 사이트로 이동하십시오. 활성 GitHub 세션이 없으면 로그인을 요구하는 프롬프트가 표시됩니다. IBM 권한 부여를 클릭하여 IBM Cloud GitHub 계정에 액세스할 수 있도록 허용합니다.
   • Personal Access Token 를 선택하는 경우 GitHub에 대해 올바른 개인 액세스 토큰을 지정하십시오.

콘솔을 사용 중이고 이미 도구 체인이 있는 경우 GitHub 도구 통합의 구성을 업데이트하십시오.

1. IBM Cloud 콘솔에서 메뉴 아이콘 > 플랫폼 자동화 > 툴체인을 클릭합니다. 도구 체인 페이지에서 도구 체인을 클릭하여 해당 개요 페이지를 여십시오. 또는 앱의 개요 페이지의 연속 배송 카드에서 툴체인 보기 > 개요를 클릭합니다.

2. 도구 체인의 개요 페이지에 있는 저장소 카드에서 GitHub 도구 통합을 찾으십시오.

3. 메뉴를 클릭하여 구성 옵션에 액세스하고 구성 설정을 업데이트하여 IBM Cloud에 GitHub 액세스 권한을 부여하십시오.

   • OAuth 를 선택하는 경우 권한 부여 를 클릭하여 GitHub 웹 사이트로 이동하십시오. 활성 GitHub 세션이 없으면 로그인을 요구하는 프롬프트가 표시됩니다. IBM 권한 부여를 클릭하여 IBM Cloud GitHub 계정에 액세스할 수 있도록 허용합니다.
   • Personal Access Token 를 선택하는 경우 GitHub에 대해 올바른 개인 액세스 토큰을 제공하십시오.

4. 설정 업데이트를 완료하면 통합 저장을 클릭하십시오.

Terraform 또는 API를 OAuth 인증 메소드와 함께 사용하는 경우 PAT (Personal Access Token) 를 사용하도록 전환하여 특정 사용자 또는 저장소에 대한 세부 단위의 액세스를 제공하십시오. Terraform 또는 API를 사용하는 경우에는 PAT를 사용하여 권한을 부여하는 것이 좋습니다. 그렇지 않으면 콘솔을 사용하여 IBM Cloud 에 GitHub 계정에 액세스할 수 있는 권한을 부여할 수 있습니다.

1. IBM Cloud 콘솔에서 메뉴 아이콘 > 플랫폼 자동화 > 툴체인을 클릭합니다. 도구 체인 페이지에서 GitHub 도구 통합을 추가할 도구 체인을 찾습니다. 툴체인을 클릭하면 개요 페이지가 열립니다.
2. 도구체인의 개요 페이지에서 추가를 클릭합니다.
3. 도구 통합 추가 페이지에서 GitHub 도구 카드를 클릭하십시오.
4. GitHub구성 페이지에서 권한 부여 를 클릭하여 GitHub 웹 사이트로 이동하십시오. 활성 GitHub 세션이 없으면 로그인을 요구하는 프롬프트가 표시됩니다. IBM 권한 부여를 클릭하여 IBM Cloud GitHub 계정에 액세스할 수 있도록 허용합니다. GitHub 구성 페이지로 리디렉션됩니다.
5. 콘솔에서 추가 조치를 수행하지 않고 페이지를 닫은 후 Terraform 또는 API와의 GitHub 도구 통합을 다시 작성하십시오.

한 지역의 내 도구 체인에 있는 Git Repos and Issue Tracking 도구 통합을 다른 지역의 도구 체인에서 사용할 수 없는 이유는 무엇입니까?

Git Repos and Issue Tracking의 인스턴스를 여러 지역에 걸쳐 사용할 수는 없습니다.

내 도구 체인에 Git Repos and Issue Tracking 도구 통합을 추가하려고 시도하면 다음 오류 메시지가 수신됩니다.

Repository URL is not valid. The repository must be on {local GitLab URL}.

여기서 {local GitLab URL}은 도구 체인이 있는 지역의 Git Repos and Issue Tracking 도구 통합의 URL입니다.

Git Repos and Issue Tracking는 실행 중인 지역에 있는 Continuous Delivery 서비스와 밀접히 통합되어 있으므로 Git Repos and Issue Tracking의 인스턴스를 여러 지역에 걸쳐 사용할 수는 없습니다.

Git Repos and Issue Tracking 도구 통합을 작성하는 대신 일반 GitLab 통합을 작성한 후 이 통합을 사용하여 다른 지역에 있는 Git Repos and Issue Tracking 저장소를 가리키십시오.

1. IBM Cloud 콘솔에서 메뉴 아이콘 > 플랫폼 자동화 > 툴체인을 클릭합니다. 도구 체인 페이지에서 이 통합을 추가할 도구 체인을 클릭하십시오. 또는 앱 개요 페이지의 Continuous Delivery 카드에서 도구 체인 보기를 클릭하고 개요를 클릭하십시오.

2. 도구 추가를 클릭하십시오.

3. 도구 통합 섹션에서 GitLab을 클릭하십시오.

4. 사용할 GitLab 서버를 클릭하십시오. 액세스할 저장소가 있는 GitLab 서버가 목록에 표시되지 않는 경우에는 사용자 정의 서버를 추가하십시오.

   a. 사용자 지정 서버를 클릭합니다.

   b. 서버의 이름을 입력하십시오. 이 서버 이름은 사용 가능한 GitLab 서버의 목록에 표시됩니다.

   c. 사용자 정의 GitLab 서버의 루트 URL을 입력하십시오.

   d. 사용자 정의 GitLab 서버의 개인 액세스 토큰을 입력하십시오. 개인 액세스 토큰이 없는 경우에는 작성하십시오.

5. GitLab 저장소가 있으며 이를 사용하려면 저장소 유형에 대해 기존을 클릭하고 URL을 입력하십시오.

6. 새 GitLab 저장소를 사용하려는 경우, 해당 저장소의 이름을 입력하고 복제하거나 분기시킬 저장소의 URL을 입력하며 저장소 유형을 선택하십시오.

   a. 빈 저장소를 작성하려면 새로 작성을 클릭하십시오.

   b. GitLab 저장소의 사본을 작성하려면 복제를 클릭하십시오.

   c. 가져오기 요청을 통해 변경사항을 제공할 수 있도록 GitLab 저장소를 분기하려면 분기를 클릭하십시오.

7. 서버에서 공용 저장소를 작성하려는 경우 이 저장소를 개인용으로 설정 선택란을 선택 취소하십시오.

8. 문제 추적을 위해 GitLab의 Issues를 사용하려는 경우 GitLab Issues 사용 선택란을 선택하십시오.

9. 커미트에 대한 태그 및 주석을 작성하여 코드 변경사항 배치를 추적하고 커미트에서 참조되는 문제에 대한 레이블 및 주석을 추적하려는 경우, 코드 변경사항 배치 추적 선택란을 선택하십시오. 자세한 내용은 툴체인으로 코드가 배포된 위치 추적을 참조하세요.

10. 통합 작성을 클릭하십시오.

GitLab 도구 통합을 구성하는 데 대한 자세한 정보는 GitLab 구성을 참조하십시오.

내 Git Repos and Issue Tracking 저장소를 https를 통해 복제할 수 없는 이유는 무엇입니까?

Git 오퍼레이션을 수행하려면 개인 액세스 토큰 또는 SSH 키를 사용해야 합니다.

https를 사용하여 명령행에서 저장소를 푸시하거나 복제하려고 하나 올바른 비밀번호를 입력해도 인증할 수 없습니다.

Git Repos and Issue Tracking는 명령행의 사용자 이름 및 비밀번호를 사용하는 Git 인증을 지원하지 않는 싱글 사인온 메커니즘을 사용합니다.

복제 또는 푸시와 같은 Git 오퍼레이션을 수행하려면 개인 액세스 토큰 또는 SSH 키를 사용해야 합니다. 개인 액세스 토큰 또는 SSH 키를 작성하는 데 대한 자세한 정보는 시작하기 튜토리얼을 참조하십시오.

SSH를 사용하여 Git Repos and Issue Tracking 저장소를 복제하려고 시도하면 인증하라는 프롬프트가 표시되는 이유는 무엇입니까?

사용자의 개인용 SSH 키의 위치 또는 권한에 문제가 있거나, Git 명령행이 Git Repos and Issue Tracking에 인증하는 데 사용자의 개인용 SSH 키를 사용하고 있지 않을 수 있습니다.

Git Repos and Issue Tracking 사용자 인터페이스를 통해 내 SSH 공개 키를 추가했습니다. SSH를 사용하여 저장소를 복제하려고 시도하면 비밀번호 또는 보안 코드에 대한 프롬프트가 표시되거나, 인증이 실패했음을 나타내는 오류 메시지가 표시됩니다.

다음 SSH 문제는 모두 인증에 대한 프롬프트를 표시하거나 오류 메시지를 표시할 수 있습니다.

• Git 명령행이 Git Repos and Issue Tracking에 인증하는 데 사용자의 개인용 SSH 키를 사용하고 있지 않습니다.

• 개인용 SSH 키가 기본 ~/.ssh/id_rsa 위치에 없습니다.

• 개인용 SSH 키에 올바른 권한(600)이 없습니다.

이 문제를 해결하려면 다음 방법을 사용하십시오.

• 기본 개인용 SSH 키 위치를 사용하는 경우에는 ~/.ssh/ 폴더 및 ~/.ssh/id_rsa 개인 키 파일에 대한 권한을 확인하십시오. 권한이 너무 광범위한 경우에는 기본적으로 SSH가 개인 키를 사용하지 않습니다. ~/.ssh/ 폴더에 대한 권한이 700으로 설정되었으며 ~/.ssh/id_rsa 폴더에 대한 권한이 600으로 설정되었는지 확인하십시오.

• 개인 키가 기본 위치에 있지 않은 경우에는 다음 명령을 사용하여 환경 변수에서 이를 지정하십시오.

  GIT_SSH_COMMAND='ssh -i/path/to/private_key_file' git clone git@host:owner/repo.git

• 연결 정보를 사용하여 이 문제를 디버그하려면 GIT_SSH_COMMAND 환경 변수에 -v 또는 -vvv 플래그를 추가하십시오.

  GIT_SSH_COMMAND='ssh -vvv git clone git@host:owner/repo.git

  GIT_SSH_COMMAND='ssh -vvv -i/path/to/private_key_file' git clone git@host:owner/repo.git

내 Git Repos and Issue Tracking 저장소에서 변경사항을 페치하려고 할 때 504 Gateway Time-out 오류가 발생하는 이유는 무엇입니까?

저장소는 1GB보다 큽니다. Git 소스 제어 관리 시스템은 대형 2진 파일을 저장하도록 설계되었습니다.

Git Repos and Issue Tracking 저장소에서 오퍼레이션을 완료하려고 할 때(예: 페치 또는 복제) 다음 오류 메시지를 수신했습니다.

git fetch error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out fatal: The remote end hung up unexpectedly

1GB보다 큰 대형 저장소가 있습니다. 저장소에는 압축된 형식으로 저장된 텍스트 파일보다 더 많은 공간이 필요한 2진 파일도 포함될 수 있습니다.

다음 방법을 사용하여 이 문제점을 해결할 수 있습니다.

• Git Repos and Issue Tracking 저장소의 크기를 줄이십시오. 리포지토리 크기를 줄이는 방법에 대한 자세한 내용은 ' ' Git'을 사용하여 리포지토리 크기 줄이기 을 참조하세요.

• SSH를 사용하여 180초의 기본 복제 제한시간을 무시하십시오.

• 저장소를 복제하려는 경우 간단한 복제(git clone --depth)를 완료하여 커미트 히스토리를 잘라 전송되는 데이터의 양을 줄이십시오. 얕은 복제본을 완성하는 방법에 대한 자세한 내용은 Git 참조 문서를 참조하세요.

이메일을 통해 내 GitLab 프로젝트에 사용자를 추가하려 시도했으나 해당 사용자가 초대를 수신하지 못했습니다. 이들을 내 프로젝트에 추가하는 방법은 무엇입니까?

초대가 해당 사용자의 이메일에 의해 차단되었을 수 있습니다.

Git Repos and Issue Tracking에 나열된 이메일을 사용하여 내 GitLab 프로젝트에 사용자를 초대했으나 해당 사용자가 이메일을 수신하지 못했습니다.

이메일이 스팸 필터에 의해 해당 사용자의 받은 편지함로부터 차단되었을 수 있습니다.

다음 방법을 사용하여 이 문제점을 해결할 수 있습니다.

• 이메일 스팸 폴더를 확인하여 이메일 초대가 스팸으로 표시되어 있는지 판별하십시오. 이메일은 noreply@ 주소로부터 발송됩니다. 이 주소의 이메일을 허용하도록 스팸 필터를 업데이트하십시오.

• 해당 사용자가 제어할 수 없는 회사 스팸 필터가 이메일을 차단하고 있는지 조사하십시오. 해당 사용자에게 Git Repos and Issue Tracking 사용자 인터페이스에 로그인하여 자신의 사용자 ID를 전송하도록 요청하십시오. 이 사용자 ID를 사용하여 해당 사용자를 GitLab 프로젝트에 추가할 수 있습니다.

Terraform을 사용하여 기존 Git 도구 통합의 구성을 업데이트할 때 구성이 실패하는 이유는 무엇입니까?

Git 도구 통합 자원은 clone, fork 또는 new 의 type 를 지정하고 기존 대상 저장소를 지정합니다.

Terraform을 사용하여 Git 도구 통합을 업데이트할 때 The nonempty repository _REPO-URL_ already exists. Either delete the repository or change the Repository Type to 'Existing' 오류 메시지와 함께 구성이 실패합니다. 여기서 REPO-URL 는 대상 저장소의 URL입니다.

이 오류는 종종 다음 조치로 인해 발생합니다.

• Git 도구 통합 Terraform 리소스는 clone, fork 또는 new 의 type 를 지정합니다. 자원의 initialization 블록 내에서 repo_url 을 존재하는 저장소의 URL로 변경했습니다.
• Git 도구 통합 Terraform 리소스는 clone, fork 또는 new 의 type 를 지정합니다. repo_url 을 변경하지 않았지만 자원의 initialization 블록 내에서 하나 이상의 다른 인수를 변경했습니다. 이 상황에서 저장소는 Terraform에서 이전에 Git 도구 통합 리소스를 적용할 때 작성되었기 때문에 존재합니다.

clone, fork 및 new 유형은 Git 도구 통합에 이 저장소가 없다는 전제 하에 대상 저장소 (repo_url) 를 작성하도록 지시합니다. 도구 통합이 대상 저장소를 찾으면 디자인에 의해 실패합니다.

type 를 clone, fork 또는 new 에서 clone_if_not_exists, fork_if_not_exists 또는 new_if_not_exists 로 변경하십시오. 이러한 유형은 Git 도구 통합에 대상 저장소가 없는 경우 이를 작성하거나 대상 저장소가 있는 경우 있는 그대로 사용하도록 지시합니다.

다른 방법을 사용하여 이 오류를 해결할 수 있지만 정보가 유실될 수 있으므로 이러한 방법은 권장되지 않습니다. 이러한 메소드를 사용하려면 우수 사례가 아닌 Terraform을 변경해야 할 수도 있습니다.

• Terraform을 다시 적용할 때 작성되는 저장소로 repo_url 를 변경하십시오. 후속 업데이트 중에 오류를 방지하기 위해 초기 작성 후 Terraform 리소스를 변경하는 것은 안티패턴입니다. 또한 이 메소드는 이전에 작성된 저장소를 그대로 두지만 더 이상 도구 체인에 바인드되지 않습니다.
• type 를 existing 로 변경한 후 Terraform을 다시 적용하십시오. 후속 업데이트 중에 오류를 방지하기 위해 초기 작성 후 Terraform 리소스를 변경하는 것은 안티패턴입니다.
• 대상 저장소를 수동으로 삭제한 후 Terraform을 다시 적용하십시오. 그렇지 않으면 자동화된 Terraform 조작 간의 수동 변경은 권장되지 않습니다. 저장소를 삭제하면 삭제를 실행 취소할 수 없으며 영구적인 데이터 손실이 발생할 수 있습니다.