pull request 전시를 삭제하는 것은 한 명령어만으로 보이지만 Capgo삭제하려면 먼저 활성 전시에서 벗어나야하고, 그 다음에 패키지 ID를 삭제해야합니다. 우리는 제한된 API 키, 전시 조회, 초기화 처리, 패키지 삭제 및 CI 자동화를 포함하는 안전한 정리 흐름을 구축할 것입니다.
목차
- 1단계: 전시 정리용으로 제한된 Capgo API 키를 생성하세요.
- 2단계: pull request 전시와 패키지 ID를 식별하세요.
- 3단계: 정리 전에 활성 전시에서 벗어나세요.
- Step 4: API ID를 가진 미리보기 패키지 삭제
- Step 5: Pull Request가 닫히면 자동으로 정리
- Step 6: 정리 확인 및 실수로 삭제를 방지하는 롤아웃 보호
- FAQ
- Conclusion
Step 1: 미리보기 정리 Capgo API 키 생성
Capgo pull request 미리보기 정리 흐름의 첫 단계는 CI 작업이 필요로 하는 작업만 수행할 수 있는 키를 만드는 것입니다.
CI 작업의 결과가 실패할 경우 명령어 또는 환경 변수가 출력될 수 있으므로, broad organization key를 pull request 워크플로에 넣지 마십시오. narrow key는 이러한 경우에 발생할 수 있는 피해를 최소화할 수 있습니다.
In Capgo, start with an App Preview key for preview work. The key should be tied to the app or preview scope that your job manages. If your team uses role-based access control, limit the key to selected apps instead of granting access across the whole organization. Capgo documents those preview key choices in its API 키 설정.
__CAPGO_KEEP_0__ 키 설정CAPGO_PREVIEW_CLEANUP_KEYCI 제공자의 암호화된 비밀 저장소에 비밀을 저장하십시오. 이름을 지정하여 무엇을 하는지 설명하십시오, 예를 들어
환경 변수를 통해 키를 청소 프로세스에 전달하세요. 스크립트는 변수가 없을 때 실패해야 합니다. silent fallback은 위험합니다. 이는 청소 작업을 인증이 없는 요청으로 만들거나 개발자가 명령줄에 키를 붙여넣도록 유도할 수 있습니다.
if [ -z "$CAPGO_PREVIEW_CLEANUP_KEY" ]; then echo "Missing preview cleanup key" exit 1
fi생산 배포 버전의 키와 분리하세요. 배포 작업은 릴리스를 업로드해야 할 수 있습니다. 청소 작업은 미리보기 리소스를 삭제하기만 하면 됩니다. 분리된 키는 검토를 쉽게하고 삭제 작업이 프로덕션 채널에 도달할 가능성을 줄입니다.
가능한 경우 보호된 환경에서 동일한 비밀을 사용하세요. 작업이 공유 채널에 접근하기 전에 승인을 요구하세요. 일반적인 pull request 미리보기 작업은 임시 채널에서만 작동해야 합니다.
주요 takeaway: dedicated App Preview 키를 사용하고, 앱 범위를 제한하고, 암호화된 CI 비밀에 저장하세요.
이전 단계를 마치기 전에 키를 무해한 읽기 작업에 테스트하세요. 작업이 의도한 앱을 볼 수 있지만 관련 없는 앱이나 프로덕션 워크플로에 접근할 수 없음을 확인하세요. 청소 작업의 정확한 요청 세부 사항은 완전히 공개되지 않았으므로 첫 번째 테스트를 작게하고 SDK 또는 Capgo 지원 지침을 검토하기 전에 삭제 호출을 추가하지 마세요.
2단계: Pull Request Preview와 Bundle ID를 식별하세요
Capgo pull request preview cleanup API 키는 작업이 미리보기 및 번들 ID를 소유한다는 것을 알고 있을 때만 유용합니다.
__CAPGO_KEEP_0__의 예측 채널 이름을 사용하는 표준화된 규칙을 사용하십시오. 일반적인 패턴은 저장소 이름에 pull request 번호를 추가하는 것입니다. 중요한 점은 일관성입니다. pull request가 닫히면 cleanup 작업이 동일한 식별자를 다시 빌드해야 합니다.
__CAPGO_KEEP_0__의 예측 채널 이름을 생성할 때 채널 이름을 저장하십시오. 워크플로우 출력, pull request 검사, 또는 작은 작업 메타데이터에 저장할 수 있습니다. 사용자 dashboard에서 변경할 수 있는 표시 이름에 의존하지 마십시오.
다음으로, 해당 예측 채널에 연결된 번들을 목록화하십시오. Capgo의 Delete Bundle 액션은 번들 ID가 필요합니다. 삭제 전에 모든 사용 가능한 번들 ID를 가져올 수 있는 목록 호출을 참조하는 소스 문서가 있습니다. 목록을 참조하여 번들 ID를 추측하지 마십시오.
반환된 레코드를 예측 채널 또는 워크플로우가 제어하는 다른 값으로 필터링하십시오. 그런 다음 정확한 번들 ID를 각각 유지하십시오. 목록이 빈 경우 cleanup을 완료로 표시하십시오. 빈 결과는 예측이 존재하지 않아도 실패가 아닙니다.
또한 각 예측에 생성된 커밋 SHA를 기록하십시오. 삭제 전에 두 번째 확인을 제공합니다. 채널 이름이 일치하지만 커밋이 일치하지 않으면 삭제를 중지하고 검토를 요청하십시오. 작은 중단은 새로운 예측이 빌드 중일 때 오래된 cleanup 작업이 실행되는 경쟁을 방지할 수 있습니다.
게시 중인 작업이 아직 진행 중일 때는 삭제하지 마세요. 미리보기 빌드와 청소 워크플로우 사이에 의존성을 추가하거나 pull request 번호에 대한 잠금을 사용하세요. 청소 작업은 close 이벤트와 미리보기 업로드가 완료된 후에만 시작해야 합니다.
Capgo의 공개 API은 채널과 번들과 같은 리소스를 인증된 HTTP 요청을 통해 관리합니다. 그러나 청소 작업은 여전히 프로젝트에서 주의 깊게 확인해야 합니다. Capgo의 공개 API 개요 __CAPGO_KEEP_0__의 공개 __CAPGO_KEEP_1__ 개요
이제 미리보기 식별자, 정확한 번들 ID 목록, 각 레코드에 묶인 커밋 SHA가 있어야 합니다. 만약 하나라도 누락된 값이 있다면 여기서 멈춥니다. 소유권 확인 없이 청소하는 것은 추측입니다.
3단계: 활성 미리보기에서 벗어나 청소하기
활성 미리보기는 삭제할 수 없습니다. 앱이 그것을 사용하고 있는 동안은 삭제할 수 없습니다. 또는 __CAPGO_KEEP_0__를 호출해야 합니다.resetPreview이것은 Capgo pull request preview cleanup 흐름의 가장 중요한 부분입니다.
Capgo의 공개 __CAPGO_KEEP_1__은 리소스를 인증된 HTTP 요청을 통해 관리합니다. 그러나 청소 작업은 여전히 프로젝트에서 주의 깊게 확인해야 합니다.
첫 번째로, 미리보기가 여전히 활성화되어 있는지 확인하세요. 만약 그렇다면, 앱을 안전한 채널로 이동하거나 업데이터 리셋 액션을 사용하세요. 올바른 선택은 테스트 앱이 구성된 방식에 따라 달라집니다. 버려질 수 있는 테스트 앱은 다시 기본 채널로 돌아갈 수 있지만 공유 테스트 앱은 전용 스테이징 채널이 필요할 수 있습니다.
사용하세요.resetPreview미리보기 상태를 직접 지우려면 사용하세요. 이 호출은 동일한 pull request와 앱과 함께 묶여야 합니다. 미리보기 삭제 스크립트는 단순히 채널 이름이 일치하는 경우에만 프로덕션 기기나 공유 릴리스 채널을 리셋하지 말아야 합니다.
이러한 규칙이 있습니다:
- pull request가 닫혔는지 확인하세요.
- 미리보기 업로드가 진행 중인지 확인하세요.
- 활성 미리보기에서 벗어나거나
resetPreview. - 상태 변경이 완료될 때까지 기다리세요.
- 그 후에 Delete Preview를 호출하세요.
HTTP 요청이 성공적으로 응답받은 것은 미리보기 assignment이 모든 기기에서 이미 상태가 변경된다는 증거가 아닙니다. 기기는 업데이트를 나중에 확인할 수 있습니다. 서버 측 클린업은 미리보기 assignment이 삭제된 후에 API 응답에 따라 진행할 수 있지만 기기 동작과 리소스 삭제를 분리하세요.
Capgo는 채널 기반 롤아웃 제어를 지원하여 이 분리를 더 쉽게 이해할 수 있습니다. 채널은 앱이 어떤 업데이트를 따를지 알려주는 이름이 붙은 경로입니다. 미리보기 채널은 프로덕션 기기에서 사용하는 채널과 동일하지 않아야 합니다.
스트릭트한 경계가 필요로 하는 팀은 문서화된 Capgo 채널 워크플로우를 사용하여 미리보기 자동화미리보기 자동화에 대한 임시 채널 패턴을 설명하며 공유 기본 채널에서 청소 작업을 멀리합니다.
오픈 소스 업데이터 문서는 삭제 한도도 기록합니다: 활성 미리보기는 switch away 또는 reset을 먼저해야합니다. Capgo Capacitor 업데이터 저장소에서 소스를 검토할 수 있습니다. 이 소스는 대시보드 문구가 CI 결정에 너무 짧을 때 유용합니다.
프로 팁: 리셋을 별도의 로그된 단계로 만듭니다. Delete Preview가 실패하면 로그에 미리보기가 활성 상태였는지 또는 삭제 요청이 다른 문제를 가지고 있었는지 표시해야합니다.
활성 상태가 사라진 후 미리보기 레코드는 삭제에 준비되어 있습니다. 리셋과 삭제를 하나의 투명한 쉘 라인으로 combination하지 마십시오. 두 개의 명확한 명령은 다시 시도하기가 더 쉬우며 감사하기도 더 쉬운 것입니다.
4단계: 미리보기 번들 ID로 삭제하기 - API 키
활성 미리보기가 리셋된 후 각 미리보기 번들을 정확한 ID로 삭제합니다. 이 때 Capgo 청소 키는 pull request로 남아있는 저장소 항목을 삭제합니다.
Step 2에서 얻은 번들 목록에서 시작하여 각 일치하는 ID에 대해 Delete Bundle 액션을 Capgo SDK 또는 현재 공공 API 방법을 통해 호출합니다.
SDK 메소드 서명 또는 Capgo 지원을 통해 현재 요청 형태를 확인하세요. 요청 형태와 응답 형식을 팀 내의 내부 실행 기록에 기록하세요. 실행 기록에는 API 버전, 필요한 식별자, 그리고 리트라이 로직이 처리할 수 있는 오류 코드를 포함해야 합니다.
스크립트에서 드라이런 모드를 사용하세요. 드라이런 모드는 삭제 요청을 보내지 않고 미리보기 채널과 삭제할 번들 ID를 출력해야 합니다. 여러 닫힌 풀 요청에 대해 드라이런 모드를 실행하세요. 프로덕션 채널을 제외하고 빈 목록을 와일드 카드로 처리하지 않도록 확인하세요.
안전한 삭제 루프에는 세 가지 게이트가 있습니다:
- 잘못된 번들 ID가 없거나 번들 ID가 잘못된 경우 거부합니다.
- 번들 채널이 풀 요청 미리보기와 일치하지 않는 경우 거부합니다.
- 소유권 확인이 통과된 후에만 삭제합니다.
그런 다음 각 응답을 유형별로 처리합니다. 성공적인 삭제는 완료로 기록할 수 있습니다. 찾을 수 없는 응답은 이전 리트라이로 삭제된 것으로 알려진 리소스가 삭제된 것으로 간주할 수 있습니다. 권한 오류는 작업을 실패시키고 소유주에게 알립니다. 속도 제한은 일시적인 실패만 리트라이하고 최대 실행 시간을 설정하여 CI 큐에 고착된 삭제 작업이 소비되지 않도록 합니다.
모든 오류를 리트라이하지 마세요. 잘못된 ID는 세 번의 시도 후에도 유효하지 않습니다. 인증 오류는 일반적으로 키 범위가 잘못된 경우입니다. 일시적인 실패만 리트라이하고 최대 실행 시간을 설정하여 CI 큐에 고착된 삭제 작업이 소비되지 않도록 합니다.
Bundle 삭제는 미리보기 삭제와 별도로 처리됩니다. 미리보기 채널을 삭제하는 것은 모든 Bundle이 삭제되었음을 자동으로 증명하지 않습니다. 각 ID에 대한 결과를 유지하고, API이 지원하는 경우 최종 목록 요청을 수행해야 합니다. Bundle이 남아 있다면 ID를 보고 중단하십시오. 성공을 암묵적으로 주장하지 말고.
삭제 로그에서 비밀을 제거하세요. 미리보기 이름, Bundle ID, 요청 결과, 타임스탬프를 로깅하는 것은 괜찮습니다. API 키, 인증 헤더, 요청 객체를 로깅하지 마십시오. 요청 객체가 하나를 포함할 수 있으므로.
이 접근 방식은 로그가 인증 정보가 유출되는 또 다른 장소가 되지 않도록 로그에 유용한 감사 기록을 제공합니다. 또한 다음 실행에서 이미 확인된 absent 레코드를 생략할 수 있으므로, 실패한 청소가 다시 시작하기 쉽습니다.
5단계: 자동화된 청소
pull request가 닫히면 청소 작업을 실행하십시오. 그러나 새로운 미리보기가 삭제되는 것을 방지하기 위해 늦은 빌드가 삭제하는 것을 방지하십시오.
워크플로우는 이벤트 페이로드에서 저장소와 pull request 번호를 받으십시오. 미리보기 채널 이름을 다시 빌드하십시오. 미리보기 채널 이름은 pull request 댓글이나 신뢰할 수 없는 branch 변수로 제공되지 않도록 하십시오.
유용한 작업 순서는 다음과 같습니다:
- 암호화된 비밀에서 제한된 청소 키를 로드하십시오.
- 이벤트가 닫힌 pull request인지 확인하십시오.
- 기대하는 저장소와 앱에 속하는 미리보기가 있는지 확인하십시오.
- 활성 미리보기 배포가 끝날 때까지 기다리십시오.
- 미리보기에서 벗어나거나
resetPreview. - 해당 미리보기를 위한 번들 ID 목록을 표시합니다.
- 인증된 번들을 삭제합니다.
- 미리보기 기록을 삭제합니다.
- 워크플로우 요약에 짧은 결과를 기록합니다.
순서가 중요합니다. 삭제를 먼저 하게 되면, 활성 미리보기 규칙이 요청을 막을 수 있습니다. 목록 호출을 건너뛰게 되면, 여전히 존재하는 번들 ID를 알 수 없습니다. guessed 이름으로 삭제를 하게 되면, 잘못된 리소스를 수정할 위험이 있습니다.
pull request 번호에 대한 동시성 규칙을 사용합니다. close 이벤트와 rebuild 이벤트가 거의 동시에 발생할 때, 이전 정리 작업이 새로운 배포와 경쟁하지 않도록 하세요. 폐기된 정리 작업을 취소하거나, 배포 잠금이 해제될 때까지 작업을 기다리세요.
Capgo의 Capgo의 한 명령 CLI 워크플로우는 빌드 및 릴리즈 작업을围싸는 커스텀 셸 호출의 수를 줄일 수 있습니다. 명령 이름 및 지원되는 작업에 대해서는 Capgo CLI 명령 문서를 확인하세요. Capgo의 Capgo 명령을 사용하여 인증된 명령을 얻을 수 있습니다. CLI 또는 공개 __CAPGO_KEEP_2__ 명령을 사용하여 직접 요청이 필요할 때 정리 작업을 수행하세요.. CLI을 사용하여 인증된 명령을 받을 때 사용하세요. SDK 또는 공개 API를 사용하여 직접 요청이 필요한 청소 작업이 필요할 때 사용하세요.
__CAPGO_KEEP_0__ __CAPGO_KEEP_1__ 명령 문서
__CAPGO_KEEP_0__
For GitHub Actions, keep permissions narrow and pass only the values needed by the cleanup step. Capgo’s current GitHub Actions integration documentation explains where the token is stored and how the workflow connects to Capgo.
__CAPGO_KEEP_2__
__CAPGO_KEEP_3__
인증이 Capgo pull request preview cleanup 루프를 종료합니다. 단순 삭제 응답만으로는 안전한 릴리스 프로세스를 보장하지 않습니다.
__CAPGO_KEEP_0__ 액션의 경우, 권한을 좁게 유지하고 cleanup 단계에 필요한 값만 전달하세요. __CAPGO_KEEP_1__의 현재 __CAPGO_KEEP_2__ 액션 통합 문서는 토큰이 저장되는 위치와 워크플로우가 __CAPGO_KEEP_3__와 연결되는 방법을 설명합니다.
이 작업의 값들을 작업 요약에 저장하세요.
- 6단계: 정리 확인 및 실수로 삭제되는 롤아웃 보호
- 페이지/영역: Capgo에 대한 페이지. 역할: UI 레이블. 표시되는 곳: about.astro 페이지에 대한 메시지 키 `about_how_step_label` (About How Step Label).
- Commit SHA를 소유권 확인에 사용하는 SHA-1 값입니다.
- 정리 작업이 완료된 후 미리보기 채널을 다시 확인하세요. 활성 미리보기로 나타나지 않는지 확인하세요. 그런 다음 동일한 앱과 필터를 사용하여 번들 목록을 확인하세요. 대상 번들 ID가 삭제되었으며 프로덕션 번들이 남아 있는지 확인하세요.
- 작업 요약에 다음 값을 저장하세요:
- 에러로 반환된 모든 ID.
명확한 상태를 사용하십시오. "청소 완료"는 모든 검증된 대상이 삭제된 것을 의미합니다. "이미 청소 완료"는 이 실행 이전에 리소스가 존재하지 않았음을 의미합니다. "검토 필요"는 하나 이상의 검사 실패를 의미합니다. 부분 삭제를 성공으로 표시하지 마십시오.
code에 프로덕션 가드를 추가하십시오. 기본 또는 릴리스 채널 이름과 같은 채널 이름을 거부하십시오. 또한 미리보기 앱의 메타데이터와 일치하지 않는 번들을 거부하십시오. 가드가 실패하면 종료되어야 합니다. 스크립트가 대상에 대한 신뢰를 가지고 식별할 수 없으면 종료되어야 합니다.
롤백과 청소는 분리되어야 합니다. 롤백은 장치가 받는 번들의 변경을 의미합니다. 청소는 이전 미리보기 리소스를 삭제합니다. pull request가 닫힌 후 테스트에서 버그가 발견되면, 조사에 사용할 수 있도록 번들을 보관하십시오. 팀이 종종 병합 후 디버깅을 수행하는 경우, 이벤트가 도착한 즉시 삭제하는 대신 짧은 보존 기간을 설정하십시오.
세 가지 일반적인 실패 패턴을 감시하십시오.
- 활성 미리보기 오류: 리셋 또는 switch away 후 Delete Preview를 다시 시도하십시오.
- 번들 ID가 누락된 경우: 리스트 액션을 다시 실행하십시오. 대신 추측하지 마십시오.
- 권한 오류: 키 범위에 대해 검토하십시오. 필요한 경우 새로운 키를 발급하십시오.
보안 정책에 따라 정기적으로 청소 키를 회전하고, 로그 또는 커밋에 나타나면 즉시 회전하십시오. 새로운 키는 이전 키가 취소되기 전에 테스트되어야 합니다. 노출이 즉시 취소해야 하는 경우 예외를 적용하십시오.
보안 검토에서 SDK 및 인증된 Capgo 지침을 참조하여 구현을 시작하고, 자신의 요청 계약을 버전 관리하십시오.
주요 takeaway: 삭제 후 미리보기 및 번들 목록을 확인하고, code에서 프로덕션 목표를 차단하고, 부분 청소가 실패로 보고하십시오.
한 명령은 가드레일이 명확할 때만 유용합니다. 미리보기 추적. 예측 가능한 채널 이름을 채택하십시오. 릴리스 변경 사항을 따로 롤백하십시오. 그런 다음 청소 작업이 라이브 트래픽에 영향을 주지 않도록 하십시오.
FAQ
활성 Capgo pull request 예시를 삭제할 수 있나요?
활성 __CAPGO_KEEP_0__ pull request 미리보기는 삭제할 수 있나요?resetPreview아니요. 활성 미리보기는 먼저 switch away해야 하거나 Capgo를 호출해야 합니다. 활성 상태가 해제된 후 Delete Preview를 실행하십시오. 이 규칙은 Capgo pull request preview 청소 API 키를 CI에서 설정할 때 기억해야 할 주요 세부 사항입니다.
Capgo 미리보기 청소에 bundle ID가 필요하나요?
네. Capgo의 Delete Bundle 액션은 bundle ID가 필요하므로, 삭제하기 전에 번들을 목록화하고, 각 ID를 미리보기 채널과 커밋과 일치시킨 후 삭제 요청을 보내십시오. branch 이름으로 ID를 빌드하거나, 미리보기 삭제가 모든 번들을 삭제한다고 가정하지 마십시오.
CI에서 API 미리보기 청소에 사용해야 하는 API 키 종류는 무엇인가요?
Capgo의 제한된 App Preview 키를 사용하여 미리 보기 정리, CI 제공자의 암호화된 비밀 저장소에 저장합니다. 앱 또는 범위에 필요한 키를 제한하고, 프로덕션 업데이트를 게시하는 데 사용하는 키와 분리합니다. 이로 인해 Capgo 정리 작업을 검토하고 rotate하는 것이 더 쉬워집니다.
pull request가 닫혔을 때 정리를 자동화할 수 있나요?
네. 닫힌 pull request 이벤트를 트리거하고, 활성 배포 작업이 완료되기 전에 미리 보기를 초기화합니다. 목록 ID, 삭제 확인된 일치, 결과 확인을 추가하고, 정리 작업과 늦은 빌드가 경쟁하지 않도록 동시성 제어를 추가합니다.
Capgo 정리 요청이 실패하는 이유는 무엇인가요?
일반적인 원인은 활성 미리 보기, 부족한 목록 ID, 또는 필요한 범위가 없는 키입니다. 미리 보기를 초기화하고, 목록 호출을 반복하고, 키 권한을 검사합니다. 요청 세부 사항은 API 또는 SDK 버전에 따라 달라질 수 있으므로, 현재 메서드와 매개 변수를 확인하기 전에 스크립트를 변경하지 마십시오.
결론
Capgo를 사용하여 전용 미리 보기 키와 엄격한 정리 순서를 사용하십시오: 활성 미리 보기 초기화, 목록 ID 목록, 삭제 확인된 패키지, 마지막으로 미리 보기 제거. 닫힌 pull request 하나에 대해 드라이 러닝을 시작하고, 현재 SDK에서 요청 형태를 확인하고, 자동 정리를 활성화하기 전에 프로덕션 채널 가드를 추가하십시오.
