팀이 반복 가능한 릴리스를 필요로 할 때 수동으로 작동하는 배포 PIPELINE을 보게 될 것입니다. 개발자는 번들을 생성하고 랩톱에서 업로드하고 대시보드를 확인하고 채널을 이동하고 그 후 수용 데이터를 기다립니다. 이러한 프로세스는 작은 프로젝트에 적합하지만 여러 앱, 환경 및 배포 작업이 동일한 인프라를 공유할 때 피할 수 있는 위험을 생성합니다.
유용한 공개 API 목록은 단순히 '어떤 엔드포인트가 존재하는가?'에 대한 답변만 제공해야 합니다. 인증, 리소스 식별자, 릴리스 상태, 할당량, 헤더, 다시 시도 및 Batch Workflow가 어떻게 연결되는지 보여줍니다. 이 안내서는 Capgo API를 운영 관점에서 다루며, CI/CD 자동화에 사용되는 Capacitor 팀에 적용되는 패턴을 제공합니다.
목차
- Capgo API 인증 이해
- API 자격 증명 생성
- 애플리케이션 관리를 위한 핵심 엔드포인트
- 릴리스 생성 및 관리
- 채널 전략 및 롤아웃 패턴
- 모니터링 및 진단 엔드포인트
- 속도 제한 및 보안 헤더
- 일반적인 API 오류 해결
Capgo API 인증 이해
첫 번째 통합 오류는 유효한 요청을 보내지만 잘못된 인증 형식으로 보내는 것입니다. 대시보드에서 복사한 키는 자동으로 비어러 토큰이 되지 않으며, 비어러 토큰은 요청이 헤더를 생략하거나 잘못된 스키마로 보내면 유용하지 않습니다. 서버는 인증 실패를 반환하기 전에 엔드포인트, 페이로드, 또는 앱 식별자를 평가하지 않습니다. Authorization 첫 단계는 현재 __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ 문서에서 인증을 호출하는 이름을 식별하고, 그 예제 요청을 정확히 재현하는 것입니다. 일반적인 비어러 토큰 요청의 경우, 인증 헤더는 다음 패턴을 따릅니다:
Start by identifying what the current Capgo API documentation calls the credential, then reproduce its example request exactly. In a typical bearer-token request, the authorization header follows this pattern:
Authorization: Bearer YOUR_TOKEN
키보드에 손가락이 움직이는 사람
인증과 권한을 분리하십시오.
__CAPGO_KEEP_0__
개인 키는 탐색을 위해 편리할 수 있지만, 하나의 사용자의 계정에 생산 자동화를 결합합니다. 팀 관리 키는 공유 pipeline에 더 적합하지만, 조직이 관련되지 않은 작업을 중단하지 않고 revocation 및 replacement을 수행할 수 있어야 합니다. 개발, 스테이징 및 생산 워크플로우에서 별도의 자격 증명을 사용하여 대시보드 및 권한 모델이 이 분리를 지원할 때.
릴리스 엔드포인트를 호출하기 전에 낮은 위험의 읽기 연산을 테스트하세요. 확인하세요:
- 호스트가 정확한지 확인하세요: API의 활성 환경에 문서화된 기본 URL을 사용하세요.
- 헤더가 완전한지 확인하세요: 필요한 인증 방식과 JSON 응답을 위한 헤더를 포함하세요.
Accept바디가 올바르게 인코딩되었는지 확인하세요: - JSON이 포함된 요청만 보내세요. Send
Content-Type: application/jsonJSON만 포함된 요청일 때만. - The host is correct: 애플리케이션 메타데이터를 읽을 수 있는 자격 증명은 릴리스를 생성하거나 배포하는 것을 허용하지 않을 수 있습니다.
- 응답은 안전하게 로그되었습니다: 상태 코드와 요청 식별자를 기록하고 키, 토큰, 번들 내용, 및敏感 장치 데이터를 비롯한 모든 정보를 비밀이되도록 지우세요.
pubilc API 카탈로그는 단순한 디렉토리에서 작동하는 탐색 도구로 성장했습니다. 프로그래머블웹의 역사적인 설명 19,000개의 API가 2018년 1월에 넘어간 디렉토리 2017년 2,294개의 새로운 API가 추가되었고, 2014년 1월 이후 매년 평균 2,000개 이상의 추가가 이루어졌습니다., after 관련 클라이언트 측 접근 제어 고려 사항은 여기서 참조하세요. 그리고 평균 이상의 2,000 년에 1회 추가 2014년 1월부터 시작된 이 역사 때문에, 현대적인 공공 API 목록은 엔지니어들이 통합 동작을 평가하는 데 도움이 돼야 합니다. 단순히 URL을 찾는 것만으로는 충분하지 않습니다.
클라이언트 측 접근 제어와 관련된 고려 사항은 여기서 참조하십시오. Capgo 앱 인증 패턴. 동일한 규칙이 적용됩니다: 신뢰할 수 있는 서버에 관리 자격 증명을 유지하고, 권한을 의도적으로 정의하고, 실패한 인증을 쉽게 진단할 수 있도록 하세요.
API 자격 증명 생성
자격 증명 생성은 접근 관리 변경으로 다루어야 합니다. 정확한 대시보드 레이블이 변경될 수 있으므로 현재 Capgo 인터페이스와 문서를 권위로 사용하세요. 그러나 워크플로우는 일관적입니다.
키 생성
조직 또는 계정 설정 영역을 열고, API 또는 개발자 자격 증명 화면을 찾고, 키 생성 액션을 선택하세요. 키 이름을 생성할 때, 해당 작업을 식별할 수 있는 이름을 지정하세요. 예를 들어, 스테이징 배포 PIPELINES 또는 프로덕션 릴리스 워커와 같은 이름을 지정하세요. 단, 사람의 이름만으로 이름을 지정하지 마세요. 팀이 변경될 때 소유권이 불명확해집니다.
권한을 최소한으로 선택하세요. 배포 상태만 읽는 작업은 애플리케이션 삭제 또는 채널 변경 권한을 받지 마세요. 인터페이스가 조직 수준과 앱 수준의 범위가 제공되는 경우, 더 작은 경계를 선택하세요.
비밀 키를 복사하세요. 많은 자격 증명 시스템은 생성 시에만 완전한 값을 표시합니다. 비밀 키를 저장하고, CI/CD 비밀 관리자에 저장한 후, 파이프라인 내에서 값이 잘못 출력되지 않도록 테스트하세요. .env file can help during development, but it must be excluded from version control and never bundled into a Capacitor web directory.
중단 없이 회전
인증된 읽기만 수행하고 나서만 旧 키를 취소하세요. 만약 서비스가 여러 개의 활성 키를 지원한다면, 모든 워커와 스케줄된 작업이 이동할 때까지 旧 값을 유지하세요.
팀의 경우, 키 소유자, 목적, 환경, 생성일, 취소 절차를 내부 접근 레지스터에 기록하세요. 비밀 자체를 레지스터에 넣지 마세요. 이로 인해 사고 대응이 실용적이지만 문서화가 또 다른 비밀 저장소가 되는 것을 피할 수 있습니다.
The API 표준 영국 정부는 OpenAPI 문서를 미리 설계하고, 입력을 검증하고, 알려지지 않은 속성을 거부하고, TLS 1.2 이상을 사용하고, OAuth 2.0을 액세스 제어로 사용하는 것을 권장합니다. 이 원칙은 API 키를 사용하는 통합에도 유용합니다: 계약을 미리 정의하고, 예상치 못한 입력을 거부하고, 수송 보안을 필수적인 것으로 간주하세요.
pipeline 저장소 및 회전 패턴을 위해 Capgo CI/CD pipeline에서 비밀 관리에 대한 지침을 사용하세요..
앱 관리를 위한 핵심 엔드포인트
애플리케이션 관리는 모든 후속 작업의 제어 평면입니다. 릴리스 생성, 채널 assignment, 배포, 및 진단 모두 안정적인 애플리케이션 식별자가 필요합니다. 실질적인 실수는 모든 작업에 인간 읽을 수 있는 앱 이름을 전달하고 그것이 고유하게 유지될 것이라고 가정하는 것입니다. 앱을 한 번 해결하고 정규식 식별자를 영구적으로 저장하고 그 식별자를 이후 작업에 사용하세요.
생산 통합은 앱 라이프 사이클을 4 가지 기능을 모델링해야 합니다.
| 작업 | HTTP 의도 | 통합 관심사 |
|---|---|---|
| 애플리케이션 목록 | GET |
페이징, 조직 범위, 안정된 식별자 |
| 하나의 애플리케이션 가져오기 | GET |
구성 버전 및 배포 관계 |
| 구성 업데이트 | PATCH 또는 문서화된 업데이트 방법 |
부분 변경 versus 전체 대체 |
| 애플리케이션 삭제 | DELETE |
irreversible 액션, 승인 및 감사 제어 |
블로그 게시물이나 오래된 SDK에서 엔드포인트 경로를 만들지 마십시오. 현재 기계-readable 정의를 읽고, 그 계약에서 타입화된 클라이언트 또는 요청 wrapper를 생성하십시오. OpenAPI 스펙 HTTP API에 대한 프로그래밍 언어 독립적인 형식으로, 엔드포인트, 인증, 요청 스키마, 응답, 그리고 소스 code 또는 네트워크 트래픽을 검사하지 않고도 사람과 도구가 발견할 수 있습니다.
식별자-첫 workflow를 구축하십시오
배포 워커는 먼저 읽기 수행하기 전에 변형 수행하기 전에 수행하십시오:
- 조직 및 애플리케이션 컨텍스트를 해결하십시오.
- 기대되는 계정에 속하는지 확인하기 위해 앱 레코드를 가져와 확인하십시오.
- 반환된 구성과 의도된 플랫폼 및 환경을 비교하십시오.
- 작업 상태에 canonical 앱 식별자를 저장하십시오.
- 그 식별자를 사용하여 제출하십시오.
- 다음 폴링과 진단을 위해 응답 식별자를 저장하세요.
이 시퀀스는 오래된 프로젝트에 대한 pipe line 변수가 올드 프로젝트를 가리키는 경우, 유효한 키가 잘못된 앱을 업데이트하는 비용이 비싼 오류를 방지합니다. 스테이징 앱을 대상으로 스테이징 작업을 요구하는 명시적 환경 주장, 쓰기 허용하기 전에 추가하세요.
응답 스키마를 사용하는 대신 느슨한 JSON 접근을 사용하세요. API이 앱 객체를 반환할 때, 식별자, 이름, 상태, 구성 필드를 포함하면, 작업이 필요로 하는 필드를 검증하고 무관한 추가를 tolerate하세요. 알려지지 않은 요청 속성을 거부하면 잘못된 구성 키를 보내지 않도록 보호하고, 클라이언트가 응답 확장에 영향을 받지 않도록 응답 파싱를 tolerate하세요.
롤백 디자인을 위해 앱 식별과 릴리즈 식별을 분리하세요. Capgo의 버전 관리 및 롤백 문서 롤백은 알려진 좋은 릴리즈 또는 채널 상태를 선택해야 하며, 애플리케이션 구성이 메모리에서 재생성되지 않아야 합니다.
릴리스 관리
업로드가 성공했음에도 프로덕션 릴리스가 실패할 수 있습니다. 아티팩트는 올바르게 저장되었지만 처리가 완료되지 않았거나, 채널 할당이 아직 이루어지지 않았거나, 업데이트를 받을 수 있는 장치가 아직 받지 못한 경우가 있습니다. 작업 흐름을 관찰 가능한 상태 변경의 시퀀스로 간주하고, 모든 작업에 대해 지속 가능한 식별자와 재시도 계획을 준비하세요.
릴리스 페이로드 준비
Capgo의 현재 스키마를 프로퍼티 이름, 요청 경로 및 필수 필드에 사용하세요. 요청 본문이 유사한 이름의 엔드포인트에서 복사된 경우 부분적으로 수락되거나 예상치 못한 이유로 거부될 수 있습니다. 실제로 payload에는 세 가지 영역이 있습니다:
- 응용 프로그램 식별자: 관련 제어 평면 작업에서 반환된 응용 프로그램 식별자입니다.
- 릴리스 메타데이터: API가 예상하는 버전, 번들 식별자, 빌드 컨텍스트 및 호환성 정보입니다.
- 배포 의도: 릴리스 작업이 지원하는 경우 채널 또는 롤아웃 컨텍스트입니다.
배포하기 전에 배포를 검증하세요. Capacitor 빌드가 예상되는 웹 자산을 포함하고 있는지, 버전이 CI 메타데이터와 일치하는지, 작업이 부분적으로 작성된 파일을 읽지 않는지 확인하세요. API이 체크섬을 수락할 경우 지역 체크섬을 계산하세요. 배포 기록에 빌드 URL, 커밋 참조 및 서버가 발행한 릴리스 식별자를 유지하세요. 나중에 업로드, 처리 및 배포 이벤트를 연관시키기 위해 업로드, 처리 및 배포 이벤트를 연관시키세요.
신뢰할 수 있는 시퀀스는 다음과 같습니다:
- 응용 프로그램을 깨끗한 작업 공간에서 빌드하세요.
- 단위, 통합 및 플랫폼별 검사를 실행하세요.
- 문서화된 릴리스 작업을 통해 번들을 생성하거나 업로드하세요.
- 운영 상태가 종료될 때까지 반환된 작업 또는 릴리스 리소스를 폴링하십시오.
- 완료된 릴리스를 의도된 채널과 연결하십시오.
- 승인 전까지 실패 신호와 수용률을 확인하십시오.
업로드 응답은 서비스에 의해 수락된 것을 확인하지만 사용자에게 전달된 것을 확인하지는 않습니다. 처리 상태, 장치의 적합성, 연결성 및 채널 멤버십은 업데이트가 장치에 도달하는지 여부를 결정합니다.
재시도는 안전해야 합니다.
Capgo이 지원하는 경우 idempotency 키를 사용하여 재시도하십시오. 재시도 시 동일한 릴리스를 제출하면 중복 또는 충돌하는 버전이 생성될 수 있습니다. idempotency 키가 없다면 릴리스 메타데이터 또는 클라이언트가 생성한 빌드 식별자를 사용하여 재시도 전에 쿼리하십시오.
Batch 업로드는 항목별 상태가 필요합니다. 각 앱 변형을 지속 가능한 큐에 넣고 독립적으로 결과를 기록하십시오. 작업 재시도 시에는 완료되지 않은 항목만 선택하여 재시도하십시오. 전체 배치를 다시 시도하는 대신 하나의 실패로 인해 모든 항목이 실패하는 것을 피하십시오. bulk 엔드포인트가 사용 가능하다면, 응답이 항목당 결과를 포함하는지 확인하십시오. 하나의 집합 성공 상태는 하나의 항목이 실패하는 것을 숨길 수 있습니다. 하나의 집합 오류는 완료된 작업을 가려줄 수 있습니다.
운영 규칙: 서버의 릴리스 식별자를 즉시 저장한 다음 처리 확인, 채널 assignment 및 진단과 같은 처리를 위해 그 식별자를 참조하십시오.
업로드 및 폴링 모두에 영향을 미치는 리미트가 있습니다. API 리미트 지침 할당량은 수행 중인 작업에 따라 반영되어야 하며 클라이언트는 사용 가능한 헤더와 재시도 동작이 필요합니다. 릴리스 생성, 상태 폴링, 검색,敏感한 변형에 대한 별도의 처리를 적용합니다. 업로드 속도로 재시도하는 폴링 루프가 정정 작업에 필요한 할당량을 소모할 수 있습니다.
리드할당량 헤더를 반환되었을 때 읽고, 서버 제공된 재시도 간격을 존중하고, 없을 때 증가하는 지연을 사용합니다. 여러 CI 작업자가 동시에 재시도하지 않도록 잡음을 추가합니다. 폴링을 제한하고, 종결 상태에 도달하면 중지하고, CI 로그에 최종 응답 본문을 포함합니다. 이 때, 인증서 및 토큰을 제거합니다. 배포를 취소한 경우, 취소한 사용자 또는 자동화 작업, 현재 릴리스 상태, 그리고 나중에 재시도할 수 있는 아티팩트가 남아 있는지 기록합니다.
채널 전략 및 배포 패턴
채널 디자인은 릴리스 관리에 대한 결정이며, 단순한 이름 지정만은 아닙니다. 스테이징, 베타, 및 프로덕션 채널은 서로 다른 사용자에게 서비스를 제공하고, 다른 프로모션 규칙이 필요합니다. 올바른 선택은 배포 패키지에 남아 있는 불확실성의 정도와 팀이 피드백을 받을 수 있는 속도에 따라 달라집니다.
| 채널 | 대상 | 검증할 사항 | 프로모션 결정 |
|---|---|---|---|
| 스테이징 | 내부 장치 및 테스트 계정 | 설치, 마이그레이션, 네이티브 호환성, 로그 | 기술 검증 통과 |
| Beta | 이른 액세스 사용자 | 실제-world 동작, 지원 피드백, 업데이트 수용 | 차단되지 않는 회귀 |
| 운영 | 일반 사용자 | 안정성, 진단, 롤백 준비 | 릴리즈 소유자가 승인 |
스테이징 채널은 결정적이어야 합니다. 알려진 테스트 장치 또는 계정 assign, 채널을 방해하지 않는 변경을 유지하고 CI가 필요한 검사 통과 후에만 승진하도록 하세요. Beta는 운영과 같은 트래픽이 중요할 때 유용하지만, 명확한 사용자 정의와 실패 보고에 대한 지원 프로세스가 필요합니다. 운영은 평범해야 합니다: 릴리즈는 이전 게이트를 통과했으며, 롤백 대상이 알려져 있으며, 모니터링이 이미 연결되어 있습니다.
The API workflow should reflect those boundaries. A pipeline can create the release once, assign it to staging, and promote the same release object after validation. Rebuilding between channels weakens traceability because the artifact tested by the team may not be the artifact distributed to users.
현재 공개 API 생태계도 유지보수와 범위가 같은 중요성을 보여주고 있습니다. API 트래커 API와 개발자 리소스를 포함하는 큰 카탈로그를 제공하며, 공공 API 리뷰 주변의 논의는 재정, 정부, 건강, 기계 학습, 기상, 교통과 같은 분야를 다루는 항목이 관리 부담을 생성한다는 것을 강조한다. 채널 카탈로그도 같은 문제를 가지고 있다:陈舊한 항목과 불분명한 소유권으로 인해 큰 목록보다는 작고 유지 관리되는 목록이 더 유용하다.
제어 테스트에 대한 구현 세부 사항은 __CAPGO_KEEP_0__ 스테이징 환경에 있는 채널을 참조하십시오. Capgo 스테이징 환경에 있는 채널.. The key pattern is to make channel movement an explicit API action with an approval boundary, rather than allowing any build job to write directly to production.
모니터링 및 진단 엔드포인트
배포 시스템에서 상관 관계 기록을 시작한다. 앱 식별자, 릴리스 식별자, 채널, 커밋 참조, 빌드 메타데이터, 요청 시간 스탬프, 그리고 마지막 API 상태를 저장한다. 지원 보고서가 도착하면, 운영자야 영향을 받은 장치에서 채널과 릴리스로 이동할 수 있어야 한다. 이는 구조화되지 않은 CI 로그를 검색하지 않고야 한다.
Start with a correlation record in your deployment system. Store the app identifier, release identifier, channel, commit reference, build metadata, request timestamp, and final API status. When a support report arrives, the operator should be able to move from the affected device to its channel and release without searching through unstructured CI logs.
__CAPGO_KEEP_0__
디버그 엔드포인트는 종종 시간 범위, 채널, 장치, 플랫폼 또는 릴리스에 대한 필터를 지원합니다. 가장 좁은 필터를 사용하여 즉시 질문에 답하십시오. 전체 설치 기반에 대한 광범위한 쿼리는 느리고, 해석하기 어려우며, 페이지네이션 또는 할당량 제한과 같은 제약 조건을 마주할 가능성이 높습니다.
실용적인 조사 순서는 다음과 같습니다:
- 릴리스 보기: 목표 릴리스가 존재하고 목표 채널에 도달했는지 확인합니다.
- 수용 보기: 적격 장치와 업데이트 발견 또는 설치한 장치와 비교합니다.
- 실패 보기: 릴리스, 플랫폼, 장치 클래스 및 설치 단계에 따라 오류를 그룹화합니다.
- 장치 보기: 특정 장치에 대한 로그를 검사하기 전에 집계 패턴이 지역 문제를 나타내는 경우에만.
- 사고 보기: 조사에 사용된原始 응답과 쿼리 매개 변수를 보존합니다.
어떤 경우에도 배포 패키지의 문제가 아니라는 것을 가정하지 마세요. 장치가 오프라인일 수 있고, 채널에서 제외되었을 수 있고, 호환되지 않는 버전을 실행하고 있을 수 있고, 앱의 업데이트 확인을 기다리고 있을 수 있습니다. 반대로, 높은 다운로드 횟수는 앱이 성공적으로 시작된다는 것을 증명하지 않습니다. 발견, 다운로드, 설치, 런타임 상태를 분리할 때 API가 노출하는 상태를 고려하세요.
자동화에 연결
일정된 워커는 릴리스 상태를 조회하고 릴리스가 pipe라인에서 허용하는 기간보다 오래 지속되는 경우 알림을 발생시킬 수 있습니다. 다른 워커는 실패 레코드를 수집하고 오류 코드를 정규화하고 배포 티켓에 첨부할 수 있습니다. 알림 페이로드는 릴리스, 채널, 필터링된 디아그노스틱 쿼리 링크와 함께 간결하게 유지하세요.
인증 및 오류 처리는 엔드포인트 호출과 같은 클라이언트 레이어에 속합니다. 워커는 자격 증명 정책에 따라 자격 증명을 갱신하거나 교체하고, 권한 부여 실패를 오류 요청과 구분하고, 다시 시도 스케줄링을 위해 응답을 보존하는 대신 일반 서버 오류로 취급하지 마세요. 429 재시도 스케줄링을 위한 응답 대신 일반 서버 오류로 처리하지 말아야 합니다.
Rate Limiting 및 Security Headers
생산 클라이언트는 다시 시도 경로를 선택하기 전에 응답 헤더를 검사해야 합니다.
응답 헤더를 캡처 X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After, 그리고 문서화된 RateLimit-* API 클라이언트 미들웨어의 필드에 대해 전달하고, 재시도 제어기와 구조화된 로그에 전달합니다. 계정, 엔드포인트 또는 작업에 따라 달라질 수 있는 code 할당량을 강제로 설정하지 마십시오.
API와 SDK capacity 정보 와 context: HTML text fragment from a longer Capgo UI string (parent key `compare_step_capacitor_text`). Page/area: Capgo marketing website. Role: Website copy sentence. Seen in: page alternatives/expo.astro, page alternatives/median.astro. Message key `compare_step_capacitor_text` (Compare Step Capacitor Text). | Page/area: Capgo marketing website. Role: Short UI label or navigation item. Seen in: page trust.astro. Message key `and` (And). retry instructions Retry-After 가 다음 요청을 결정합니다. 남은 카운트 헤더는 클라이언트가 한계에 얼마나 가까운지 보여줍니다.
Rows of server racks in a modern data center with blue cables and blinking status lights.
Keep Capgo management requests on a trusted backend or CI runner. A Capacitor application may call a narrow application-facing service, but it should never receive credentials that can modify releases, channels, or organization resources. Enforce TLS, validate bodies, and remove authorization headers from traces and error reports.
API 관리 요청을 신뢰할 수 있는 백엔드 또는 CI 러너에서 유지하십시오. __CAPGO_KEEP_1__ 애플리케이션은 좁은 애플리케이션 대면 서비스를 호출할 수 있지만, 릴리스, 채널 또는 조직 리소스를 수정할 수 있는 자격 증명을 받지 마십시오. TLS를 강제하고, 본문을 검증하고, 추적 및 오류 보고서에서 인증 헤더를 제거하십시오. 속도 제한 보안 지침.
모든 요청에 타임아웃을 사용하고 HTTP 응답과 전송 오류를 구분하십시오. 타임아웃은 변형의 결과를 알 수 없으므로 다시 시도하기 전에 상태를 확인하십시오. 429 응답은 서버의 명시적 피드백이며 클라이언트는 헤더에서 다음 시도를 예약해야 합니다.
Capacitor 배포에 대해 Capgo의 API 속도 제한 지침은 앱 스토어 준수에 대한 관련 운영 참조를 제공합니다. 개인 키를 분산하여 권한 오류를 해결하지 마십시오.
API 오류를 해결하는 방법
대부분의 오류는 인증, 유효성 검사, 및 제한 3 가지 그룹으로 분류됩니다. 오류 그룹을 진단하기 전에 code을 변경하지 마십시오.
응답 상태, 구조화된 오류 본문 및 관련 헤더는 다음 동작을 선택하기에 충분한 정보를 제공합니다.
인증 오류 401 or equivalent authorization response usually means the credential is missing, malformed, expired, revoked, or sent with the wrong scheme. Check the environment variable inside the actual CI job, not only in the local shell. Confirm that the request includes the exact header format from the current API documentation, then test the credential against a read-only operation.
환경 변수를 확인하기 전에 CI 작업의 실제 셸에서 확인하십시오. 현재 __CAPGO_KEEP_0__ 문서에서 제공하는 정확한 헤더 형식을 포함하는 요청을 확인하고 인증 정보를 읽기 전용 연산과 테스트하십시오.
잘못된 요청 본문
유효성 검사 응답은 서버가 요청을 받았지만 구조 또는 값이 거부된다는 것을 의미합니다. 현재 스키마와 비교하여 payload를 검사하고, 필수 필드, 타입, 열거형 값, 중첩 객체 및 식별자에 주의를 기울여보세요. 지원되지 않는 필드를 제거하는 대신 서비스가 그들을 무시하길 기대하지 마세요.
로그에 레드랙트된 payload와 응답의 field-level 오류를 기록하고 CI에 스키마 유효성을 추가하여 업로드가 시작되기 전에 잘못된 릴리스 메타데이터가 실패하도록 하세요. 만약 연산이 부분 업데이트라면, 완전한 대체 대신 패치 스타일 본문을 기대하는 엔드포인트가 있는지 확인하세요.
잠금 및 모호한 변형
A 429 A Retry-After 서버가 다시 시도하는 지침을 따르도록 작업자가 요청을 보내지 않도록 하며,
가 있는 경우, 지연 시간의 fallback 계산에서 잡을 적용하고, 여러 동시 작업자가 동일한 순간에 다시 시도하는 것을 방지합니다. 업로드 또는 릴리스 생성 중 시간 초과가 발생한 경우, 즉시 다른 변형을 제출하지 마세요. 클라이언트가 생성한 빌드 참조 또는 반환된 식별자가 있는 경우, 연산을 검색하거나 반환된 식별자로 연산을 검색하세요. 식별자가 없으면, 원래 요청이 완료되었는지 API의 문서화된 지원 또는 중복성 메커니즘에 문의하세요. 이로 인해 중복 릴리스가 발생하지 않고 최종 배포 기록이 신뢰할 수 있는지 확인하세요.
Capgo provides a public REST API for managing app delivery resources, releases, channels, devices, and related deployment workflows, so teams can connect live-update operations to their existing CI/CD and monitoring systems. Review the current Capgo production promotion을 자동화하기 전에, 최소한의 권한을 가진 테스트 자격증서를 생성하고, 완전한 릴리스 및 롤백 경로를 검증해야 합니다.
