Nightly Release
Tideclaw/OpenClaw 알파/나이틀리 릴리스 자동화, 수동 알파 트리거, 베타 준비, 릴리스 브랜치 수리, 및 포스트 릴리스 포워드 포트에 사용됩니다. Tideclaw 호스트 경로, cron ID, 또는 Discord 라우팅 ID를 사용하기 전에 $release-private이 존재하면 로드하십시오.
정책
- 알파/나이틀리는 12시간마다 또는 수동 트리거로 실행됩니다.
- 베타는 입증된 알파/릴리스 브랜치에서 Discord를 통해 사람이 트리거합니다.
- Stable/latest는 항상 명시적인 사람의 확인이 필요합니다.
- 더티 체크아웃이나
main에서 직접 게시하지 마십시오. - Main은 바쁘거나 손상될 수 있습니다. 알파 작업은 격리되어야 하므로 일시적인 main 실패가 사용 가능한 nightly를 차단하지 않아야 합니다.
- 릴리스 브랜치 증명이 통과한 후에만 게시하십시오.
- 성공적인 알파 후, 릴리스 브랜치 커밋을
main으로 포워드 포트하고 main CI가 통과했는지 확인하십시오. - 포워드 포트 PR은 nightly/release 검사를 통과시키는 데 필요한 재사용 가능한 수정 사항만 포함해야 합니다. 알파 버전 범프, 릴리스 노트, 체인지로그 릴리스 항목, 태그, 생성된 아티팩트 또는 상태 파일 업데이트를 포함해서는 안 됩니다.
- 최근 3일 이내의 알파/나이틀리 브랜치와 활성 실행, 열린 PR 또는 릴리스 태그가 있는 브랜치만 유지하십시오.
- 광범위한 env/token 덤프를 실행하지 마십시오. Tideclaw 호스트에서 GitHub 쓰기의 경우 아래 Tideclaw
gh쓰기 래퍼를 사용하십시오.
Identity
Tideclaw는 릴리스 브랜치와 포워드 포트 브랜치에서 자체 머신 아이덴티티로 커밋해야 합니다:
git config user.name "Tideclaw"
git config user.email "[email protected]"
커밋이 명확히 머신에 의해 작성되고 CI에 의해 제어된다면 이는 감사 추적에 좋습니다. 보호된 main에 직접 푸시하는 것을 피하고, PR/automerge를 통해 포워드 포트하십시오. 단, 저장소 정책이 봇이 녹색 검사 후 푸시하는 것을 명시적으로 허용하는 경우는 예외입니다. 사람이 패치나 명시적인 커밋 텍스트를 제공한 경우에만 Co-authored-by를 포함하십시오.
Branch Shape
- 브랜치 접두사:
tideclaw/alpha/ - 브랜치 이름:
tideclaw/alpha/YYYY-MM-DD-HHMMZ - 베이스: 트리거 시점의 현재
origin/mainSHA. - 상태 파일: Tideclaw 호스트의
$release-private에서 확인. - 릴리스 태그:
vYYYY.M.PATCH-alpha.N - npm dist-tag:
alpha
PATCH는 순차적인 월별 릴리스 트레인 번호이며, 달력 날짜가 아닙니다. 안정 및 베타 릴리스에서 알파 트레인을 결정하십시오. 다음 트레인을 선택할 때 알파 전용 패치 번호는 무시하십시오. 해당 월의 가장 높은 stable/beta 패치보다 하나 큰 값을 사용하고, 해당 트레인에서 반복 nightly에 대해서만 alpha.N을 증가시키십시오. 다음 패치에 베타가 이미 존재하면 알파를 다음 트레인으로 이동하십시오. 부풀려진 패치 번호를 가진 레거시 알파 전용 태그는 beta/stable 번호를 진행시키지 않습니다.
새로운 실행을 위해 오래된 알파 브랜치를 재사용하지 마십시오. 동일한 베이스 SHA를 다시 실행하는 경우, 새로운 타임스탬프 브랜치를 생성하고 이유를 기록하십시오.
시작
$release-private의 Tideclaw 호스트 체크아웃에서 작업하십시오.- 먼저 패치:
git fetch origin main --tags --prune
git switch main
git merge --ff-only origin/main
BASE_SHA="$(git rev-parse origin/main)"
BRANCH="tideclaw/alpha/$(date -u +%Y-%m-%d-%H%MZ)"
git switch -c "$BRANCH" "$BASE_SHA"
- 변경하기 전에 저장소 릴리스 문서/스크립트를 읽으십시오:
AGENTS.mddocs/아래의 릴리스 문서scripts/아래의 릴리스 스크립트.github/workflows/*release*
$BASE_SHA를 마지막 성공적인 알파 상태 및 현재 git/npm/GitHub 알파 태그와 비교하십시오. 이미 릴리스된 경우 건너뛰기로 보고하고 게시하지 마십시오.
수동 트리거:
CRON_ID="<from release-private>"
OPENCLAW_ALLOW_ROOT=1 openclaw cron run "$CRON_ID" --expect-final --timeout 21600000
Discord Alpha Trigger
Tideclaw는 관리자가 #releases 또는 #maintainers에서 Tideclaw를 언급할 때 Discord에서 즉시 알파를 실행할 수 있습니다.
허용된 형식:
@Tideclaw run alpha now
@Tideclaw alpha release from main now
@Tideclaw trigger alpha
규칙:
- 이것을 알파 cron 작업과 동등한 수동 알파 트리거로 취급하십시오.
- 현재
origin/main에서 시작하여 새로운tideclaw/alpha/YYYY-MM-DD-HHMMZ브랜치를 만드십시오. - 일반 알파 워크플로우를 따르십시오: 이전 수정 사항 재사용, 로컬 검사 실행, 알파 브랜치에서 수정, 릴리스 CI 실행, 녹색 게이트 후 알파 게시, 그런 다음 수정 사항 전용 PR을 통해 재사용 가능한 수정 사항을 포워드 포트하십시오.
- 다른 알파/베타/안정 릴리스 실행이 이미 활성 상태인 경우, 활성 브랜치/실행을 보고하고 중지하십시오.
#maintainers트리거는 명시적인 Tideclaw 언급이 필요합니다. 언급되지 않은 릴리스 채팅에 반응하지 마십시오.- Discord 역할/사용자 ID 및 라이브 호스트 핫픽스 노트를
$release-private에서 확인하십시오.
Discord Beta Trigger
Tideclaw는 관리자가 명시적인 베타 트리거를 보낼 때만 #releases 또는 언급된 #maintainers 명령에서 베타 릴리스를 실행할 수 있습니다. 이것을 베타에 대한 사람의 승인으로 취급하고, stable/latest에 대한 승인으로 취급하지 마십시오.
허용된 형식:
@Tideclaw beta release from vYYYY.M.PATCH-alpha.N
@Tideclaw beta release from tideclaw/alpha/YYYY-MM-DD-HHMMZ
@Tideclaw beta release from latest proven alpha
규칙:
beta release단어와 소스 알파 태그/브랜치 또는latest proven alpha가 필요합니다.- 소스가 모호한 경우,
#releases에서 명확한 질문을 하나 하고 중지하십시오. - 먼저 소스 알파를 확인하십시오: GitHub 릴리스, npm
alpha패키지, 릴리스 CI, 기록된 상태 파일, 브랜치/태그 SHA. - 움직이는
main에서 직접이 아니라 입증된 알파 소스에서 새로운 베타 브랜치tideclaw/beta/YYYY-MM-DD-HHMMZ를 만드십시오. - 이미 알파에서 입증된 안정화 수정 사항만 재사용/스쿼시하십시오. 베타 릴리스 문서가 요구하지 않는 한 관련 없는 알파 릴리스 메커니즘을 가져오지 마십시오.
- 베타를
vYYYY.M.PATCH-beta.N으로 계산하고, npm--tag beta와 일치시킵니다. 베타 트레인을 선택할 때 알파 전용 패치 번호는 무시하십시오. - 베타 릴리스 검증/사전 점검/전체 릴리스 CI를 실행하고 베타 브랜치에서 실패를 수정하십시오.
- 녹색 베타 게이트 후에만 베타를 게시하십시오. GitHub Actions/OIDC를 사용하고, 호스트에서 직접 npm 게시하지 마십시오.
- 최종 Discord 요약에는 소스 알파, 베타 태그/버전, 브랜치, 수정 커밋, 워크플로우 실행 ID, npm/GitHub 증명, 및 건너뛰거나 차단된 이유가 포함되어야 합니다.
- 베타 게시 후, 아래의 동일한 수정 사항 전용 PR 규칙을 사용하여 재사용 가능한 수정 사항을
main으로 포워드 포트하십시오.
이전 수정 사항 재사용
검사를 실행하기 전에, 이전 릴리스 시도 중에 이루어진 최근 Tideclaw 알파 브랜치에서 수정 사항을 찾으십시오:
$release-private에서 마지막 성공적인 알파 브랜치 및 수정 커밋 SHA에 대한 Tideclaw 상태 파일을 읽으십시오.- 최근 원격 브랜치를 나열하십시오:
git for-each-ref refs/remotes/origin/tideclaw/alpha --format='%(refname:short) %(committerdate:iso-strict)'
- 최근 3일 이내의 Tideclaw 알파 브랜치와 마지막 성공적인 알파 브랜치만 고려하십시오.
- 각 후보 브랜치에 대해, 현재
origin/main에 없는 커밋을 검사하십시오:
git log --no-merges --reverse --format='%H%x09%s' origin/main..origin/tideclaw/alpha/YYYY-MM-DD-HHMMZ
- 새 알파 브랜치에 여전히 적용되는 실제 안정화 수정 사항만 체리픽하십시오. 상태 파일에
fixCommitShas로 기록된 커밋을 선호하십시오. - 버전 범프, 체인지로그 릴리스 항목, 태그 아티팩트, 생성된 릴리스 노트, 상태 파일 전용 커밋, 및 일회성 디버그 계측은 건너뛰십시오.
- 체리픽이 충돌하는 경우, 현재 main에 동등한 수정 사항이 이미 포함되어 있는지 검사하십시오. 그렇지 않은 경우, 최소한으로 해결하고 커밋 메시지를 명확하게 유지하십시오.
- 재사용된 커밋 SHA를 새로 작성된 수정 SHA와 별도로 알파 상태 및 최종 Discord 요약에 기록하십시오.
git cherry, git range-diff, 및 대상 테스트 재실행을 사용하여 이미 main에 있는 수정 사항을 복제하지 마십시오.
수리 루프
브랜치를 릴리스 후보 수리 표면으로 사용하십시오:
- 먼저 좁은 로컬 검사를 실행하십시오: 변경된 테스트, 릴리스 사전 점검, 릴리스 문서에 필요한 유형/린트/빌드 게이트.
- 로컬 검사가 실패하면, 최소 커밋으로 알파 브랜치에서 수정하십시오.
- 각 일관된 수정 사항을 Tideclaw로 커밋하십시오.
- 각 수정 후 실패한 로컬 검사를 다시 실행하십시오.
- 릴리스 문서가 명시적으로 요구하고 diff가 정당화되지 않는 한, 기준선, 예상 실패 목록, 무시 파일 또는 릴리스 인벤토리를 편집하여 실패를 숨기지 마십시오.
- 실패가 불안정한 경우, 한 번 다시 실행하십시오. 여전히 빨간색이면 실제로 취급하십시오.
- 수정 사항이 main에 분명히 유용한 경우, 작게 유지하고 포워드 포트 가능하게 하십시오. 알파 안정화 중에는 광범위한 리팩터를 피하십시오.
커밋 예시:
git add <files>
git commit -m "fix: stabilize alpha release preflight"
git push -u origin "$BRANCH"
릴리스 CI
로컬 증명 후:
- 기존 git 태그, npm 버전 및 GitHub 릴리스에서 다음
vYYYY.M.PATCH-alpha.N을 계산하십시오.PATCH를 stable/beta 트레인에서 선택하고, 날짜나 가장 높은 알파 전용 패치가 아닌 것을 선택하십시오. 동일한 알파 트레인을 재사용하고 해당 패치에 베타가 있을 때까지alpha.N을 증가시키십시오. 베타가 존재한 후에는 새 알파 빌드에 다음 패치를 사용하십시오. - 알파 브랜치 패키지 버전 및 릴리스 메타데이터가 해당 태그와 일치하도록 하고, 커밋한 다음 브랜치를 푸시하십시오.
- 브라우저/패치 도구가 아닌 GitHub CLI를 사용하여 알파 브랜치에서 릴리스 검증을 실행하십시오. Tideclaw 호스트에서 기본
gh는 읽기 전용 Codex 샌드박스 래퍼입니다.workflow run,run cancel및 게시 디스패치와 같은 쓰기 가능 명령에는/usr/local/bin/gh-tideclaw-write를 사용하십시오:
GH="/usr/local/bin/gh-tideclaw-write"
SHA="$(git rev-parse HEAD)"
TAG="v$(node -p "require('./package.json').version")"
BRANCH="$(git branch --show-current)"
"$GH" workflow run full-release-validation.yml --repo openclaw/openclaw --ref "$BRANCH" \
-f ref="$BRANCH" \
-f release_profile=beta \
-f rerun_group=all
"$GH" workflow run openclaw-npm-release.yml --repo openclaw/openclaw --ref "$BRANCH" \
-f tag="$SHA" \
-f preflight_only=true \
-f npm_dist_tag=alpha
gh run list,gh run view, 및gh api로 정확한 워크플로우 실행 ID와 헤드 SHA를 모니터링하십시오. 읽기 전용gh는 폴링에 적합합니다. 명령이 GitHub를 변경할 때만$GH를 사용하십시오. GitHub API 폴링에 Codex 브라우저/패치를 사용하지 마십시오. 이전 Tideclaw 실행은 성공적인 사전 점검 후에 거기서 실패했습니다.- 알파의 경우, Tideclaw가 직접 수리할 수 있거나 패키지 안전성을 입증하는 게이트만 차단 게이트입니다: 정상 CI, 플러그인 사전 릴리스, npm 사전 점검, 패키지 준비, 설치 스모크, 태그/도달 가능성, 게시 검증. 교차 OS, 라이브 채널, QA Lab, 패키지 승인, 긴 Docker E2E, Telegram 패키지 E2E 실패는 참고 사항으로 취급하십시오. Discord에 보고하고 차단 게이트가 녹색이면 계속 진행하십시오.
rerun_group=all이 참고 레인에서만 멈추고 CI, 플러그인 사전 릴리스, npm 사전 점검, 패키지 준비, 설치 스모크가 녹색인 경우, 동일한 헤드에서-f rerun_group=install-smoke로 집중된 전체 릴리스 검증을 디스패치하십시오. 해당 성공적인 집중 전체 릴리스 검증 실행을 게시 증명으로 사용하고, 별도의 CI/플러그인/참고 실행 ID를 Discord 요약에 포함하십시오.
- 차단 게이트가 실패하면, 알파 브랜치에서 수정하고 푸시한 후, 실패하거나 필요한 릴리스 CI만 다시 실행하십시오. 커밋이 변경되면, 이전 사전 점검/전체 검증 실행 ID를 폐기하고 새 헤드에 대해 다시 실행하십시오.
- 동일한 브랜치 헤드에서 전체 검증 및 npm 사전 점검이 녹색이면, 해당 정확한 커밋에서 릴리스 태그를 생성하고 푸시하십시오:
git tag -a "$TAG" "$SHA" -m "openclaw ${TAG#v}"
git push origin "$TAG"
- 동일한 알파 브랜치에서 게시 래퍼를 디스패치하십시오. 성공한 npm 사전 점검 실행 ID와 전체 릴리스 검증 실행 ID 및 동일한 헤드 SHA의 정확한 시도를 사용하십시오:
FULL_RELEASE_VALIDATION_RUN_ATTEMPT="$(gh api \
"repos/openclaw/openclaw/actions/runs/${FULL_RELEASE_VALIDATION_RUN_ID}" \
--jq .run_attempt)"
"$GH" workflow run openclaw-release-publish.yml --repo openclaw/openclaw --ref "$BRANCH" \
-f tag="$TAG" \
-f preflight_run_id="$NPM_PREFLIGHT_RUN_ID" \
-f full_release_validation_run_id="$FULL_RELEASE_VALIDATION_RUN_ID" \
-f full_release_validation_run_attempt="$FULL_RELEASE_VALIDATION_RUN_ATTEMPT" \
-f npm_dist_tag=alpha \
-f plugin_publish_scope=all-publishable \
-f publish_openclaw_npm=true \
-f release_profile=beta \
-f wait_for_clawhub=false
- 게시 래퍼 및 하위 실행을 모니터링하십시오.
openclaw-npm-release.yml이npm-release환경을 기다리고 있고 Tideclaw가 승인할 수 없는 경우, 그것만이 유일한 차단자라고 보고하십시오. 릴리스가 완료되었다고 말하지 마십시오. - 호스트에서 직접 npm을 게시하지 마십시오. GitHub Actions/OIDC를 사용하십시오.
중요: preflight_only=true인 openclaw-npm-release.yml은 아티팩트만 준비합니다. 게시하지 않습니다. 성공적인 알파는 이후의 openclaw-release-publish.yml 래퍼, 푸시된 git 태그, npm alpha dist-tag 증명, 및 GitHub 사전 릴리스가 필요합니다.
게시된 알파 확인
릴리스는 다음이 모두 참일 때까지 완료되지 않습니다:
- GitHub 태그가 존재합니다.
- GitHub 릴리스가 존재하고 사전 릴리스로 표시됩니다.
- 릴리스 본문이 npm 버전 페이지, 레지스트리 타볼, 무결성, 및 CI/증명에 링크됩니다.
npm view openclaw@<version>이 정확한 버전, dist-tagalpha, 타볼, 무결성, 및 게시 시간을 표시합니다.- 설치/패키지 스모크가 저장소 릴리스 문서를 따릅니다.
$release-private의 Tideclaw 상태 파일이 버전, 태그, 베이스 SHA, 브랜치, 수정 커밋 SHA, 워크플로우 실행 ID, npm 무결성, 및 타임스탬프를 기록합니다.
#releases의 최종 Discord 요약:
- 태그/버전
- 베이스 SHA
- 브랜치
- 수정 커밋
- 워크플로우 실행 ID
- npm/GitHub 증명
- 릴리스되지 않은 경우 건너뛰거나 차단된 이유
Discord-safe Markdown 링크를 앵글 브래킷 대상과 함께 사용하십시오. 비밀을 절대 인쇄하지 마십시오.
포워드 포트
성공적인 알파 후, main으로 수정 사항 전용 PR을 올리십시오:
- 현재
origin/main에서 포워드 포트 브랜치를 생성/업데이트하십시오:
git fetch origin main --prune
git switch -c "tideclaw/forward-port/$(date -u +%Y-%m-%d-%H%MZ)" origin/main
- nightly/release 검사를 통과시키는 데 필요한 실제 수정 사항인 릴리스 브랜치 커밋만 체리픽하십시오.
- 알파 버전 범프, 체인지로그 릴리스 항목, 릴리스 노트, 태그 아티팩트, 생성된 릴리스 자산, 상태 파일 전용 커밋, 및 게시 알파만을 목적으로 한 커밋은 제외하십시오.
- 커밋이 실제 수정 사항과 릴리스/버전 변경을 혼합하는 경우, 분할하십시오: 더 명확한 역사를 위해 수정 청크만 새 커밋에 재생하고 릴리스 변경 사항은 포워드 포트 PR에서 제외하십시오.
tideclaw/forward-port/브랜치를 push하고origin/main을 base로 하는 PR을 생성하십시오:
git push -u origin "$BRANCH"
"$GH" pr create --repo openclaw/openclaw \
--base main \
--head "$BRANCH" \
--title "fix: forward-port nightly fixes from $(date -u +%Y-%m-%d)" \
--body "$(echo -e \"## 설명\\n\\nTideclaw 알파 릴리스 과정에서 필요한 수정 사항을 포워드 포트합니다.\\n\\n## 수정 사항\\n\"\"\"\
for sha in $(git log --reverse --format='%H' origin/main..HEAD); do
echo "- $(git log -1 --format='%s' $sha) ($sha)"
done)\
\"\"\"\n\n## 체크리스트\n- [ ] 알파 버전 범프 없음\n- [ ] 체인지로그/릴리스 노트 항목 없음\n- [ ] 태그 또는 생성된 아티팩트 없음\n- [ ] Main CI가 이 PR로 통과함\""
- PR이
origin/main에 대해 병합 가능한지 확인하고 CI가 통과하는지 확인하십시오. - 자동 병합을 활성화하거나 리뷰어를 요청하십시오. Tideclaw가 직접 병합해서는 안 됩니다.
- main CI가 녹색이 될 때까지 기다리십시오. 실패하면 알파 브랜치의 추가 수정이 필요할 수 있습니다.
중요: 포워드 포트 PR은 항상 수정 사항 전용이어야 합니다. 알파 메커니즘, 게시 아티팩트, 또는 nightly/릴리스 검증과 직접 관련되지 않은 변경 사항을 포함하지 마십시오.
브랜치 정리
성공적인 알파 게시 후, 오래된 알파 브랜치를 정리하십시오:
for branch in $(git branch -r --merged origin/main | grep 'origin/tideclaw/alpha/' | head -n -3); do
# 최근 3개 유지, 나머지 삭제
git push origin --delete "${branch#origin/}"
done
다음은 유지하십시오:
- 최근 3일 이내의 브랜치.
- 활성 GitHub Actions 실행이 있는 브랜치.
- 열린 PR이 있는 브랜치.
- 릴리스 태그가 있는 브랜치.
오류 처리
예기치 않은 오류 발생 시:
- 영향을 받는 릴리스 실행을 취소하십시오.
- 연결된 GitHub Actions 실행을 취소하십시오.
- 문제를
#releases에 명확한 설명과 함께 보고하십시오. - 가능하고 안전한 경우, 문제를 식별하고 최소한의 수정 사항만 포함하는 새 알파 브랜치로 재시도하십시오.
- 연속 3회 실패 후 Tideclaw 알파를 중단하고
#maintainers에 사람의 개입을 요청하십시오. - Cron 실패의 경우: 수동 재시도가 가능하고 적절하다면,
$release-private의 cron ID를 사용하여 수동 트리거를 실행하십시오.
상태 파일
Tideclaw는 $release-private에 릴리스 상태 파일을 유지합니다. 형식은 다음과 같습니다:
# 릴리스 상태 - Tideclaw에 의해 관리됨
lastSuccessfulAlpha:
version: vYYYY.M.PATCH-alpha.N
tag: vYYYY.M.PATCH-alpha.N
baseSha: abc123...
branch: tideclaw/alpha/YYYY-MM-DD-HHMMZ
fixCommitShas:
- def456...
- ghi789...
workflowRunIds:
validationRunId: 12345
preflightRunId: 67890
publishRunId: 11121
npmIntegrity: sha512-...
timestamp: 2024-01-01T00:00:00Z
게시하기 전에 이 파일을 읽고 성공적인 릴리스 후에 업데이트하십시오.
보안 고려 사항
- 호스트에서 비밀을 절대 인쇄하지 마십시오.
- 모든 게시는 GitHub Actions/OIDC를 통해 이루어져야 하며, 직접 호스트 게시가 아닙니다.
- 읽기 전용 작업에는 기본
ghCLI를 사용하고, 쓰기 작업에는/usr/local/bin/gh-tideclaw-write를 사용하십시오. - Discord 메시지에 민감한 값을 포함하지 마십시오.
- 모든 작업은 릴리스 상태 파일과 CI 로그를 통해 감사 가능해야 합니다.
예시 실행 흐름
- 트리거: cron (12시간마다) 또는 수동 (
@Tideclaw run alpha now) - 패치 및 새 알파 브랜치 생성
- 이전 수정 사항 재사용 (선택 사항)
- 로컬 검사 실행 및 알파 브랜치에서 수정
- 릴리스 CI 실행 (전체 검증, npm 사전 점검)
- 게이트가 녹색이면 태그 생성 및 푸시
- 게시 래퍼 디스패치
- 게시 확인 (GitHub, npm, 설치 스모크)
- 수정 사항 전용 PR을 main으로 포워드 포트
- Discord 요약
- 오래된 알파 브랜치 정리
- 성공 시 상태 파일 업데이트