메뉴
Manage CI bundle releases: manual dispatch, tag naming, monitoring the build-bundle workflow, promoting a release, and rolling back. Use when releasing a new bundle, debugging a CI failure, or rolling back to a previous bundle.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | atlas-ci-release |
| description | Manage CI bundle releases: manual dispatch, tag naming, monitoring the build-bundle workflow, promoting a release, and rolling back. Use when releasing a new bundle, debugging a CI failure, or rolling back to a previous bundle. |
atlas-build-bundle).github/workflows/build-bundle.yml manually)Go to GitHub → Actions → Build Bundle → Run workflow.
Parameters:
| Parameter | Value | When |
|---|---|---|
model_id | Xenova/bge-small-en-v1.5 | Default — production builds |
ref | main | Stable releases |
ref | <branch> | Testing a feature branch |
Do NOT dispatch from main if there are unmerged changes that affect the bundle content.
Tags are auto-generated from the workflow run: bundle-<YYYYMMDD>-<run_number> (e.g., bundle-20260622-42).
For manual tags (when the auto-tag is insufficient):
git tag bundle-<YYYYMMDD>-<run_number>-<reason>
git push origin bundle-<YYYYMMDD>-<run_number>-<reason>
Reasons: hotfix, rollback, rc1, rc2.
The workflow takes ~30–60 minutes.
| Phase | Duration | Key log lines |
|---|---|---|
| Setup | 1 min | Setup uv, Cache npm |
| Clone docs | 2–3 min | Cloning servicenow-docs |
| Chunk | 2–5 min | Chunked N files |
| Download model | 1–3 min | Downloading Xenova/bge-small-en-v1.5 |
| Embed | 15–30 min | Embedding chunk N/M |
| Package | 1 min | Creating tarball |
| Smoke test | 2 min | Smoke test passed |
| Publish | 1 min | Uploading release asset |
If the workflow exceeds 60 minutes, check the runner logs for:
When the build workflow succeeds:
gh release edit <tag> --latest
To revert to a previous bundle:
# Find the previous release's tag
gh release list --limit 10
# Download the previous bundle
gh release download <previous-tag> --pattern '*.tar.zst'
# Make it the latest
gh release edit <previous-tag> --latest
No code rollback is needed — bundles are independent artifacts. Just re-point consumers.
File: .github/workflows/build-bundle.yml
| Key detail | Value |
|---|---|
| Trigger | Monthly cron (0 6 1 * *) + workflow_dispatch |
| Runner | ubuntu-latest (2 vCPU, 7 GB, no GPU) |
| Model | Xenova/bge-small-en-v1.5 (int8, 384-dim) |
| Backend | ONNX+CPU (forced via --backend onnx-cpu) |
| Batch size | 256 |
| Env | HF_TOKEN set from secrets |
| Post-build | atlas-smoke |
| Artifact | GitHub Release (auto-tag) |
Patterns for keeping READMEs accurate as code evolves. Focused on structural consistency, not prose style. Use when editing a README with ASCII tree diagrams, version callouts, config examples, or cross-document line ranges. Avoids generic "write clearly" advice — targets the concrete rot patterns that accumulate in docs-heavy repos.
Aggressive optimization patterns for atlas. Overrides standard Python defaults with zero-dep, startup-time, and memory-efficient alternatives. Honed for a project that runs a read-only parquet-backed RAG bundle loaded into numpy at startup and queried via MCP. Use when making any code change — these patterns take precedence over generic Python best practices.
Write and maintain Architecture Decision Records (ADRs) for the atlas project. Covers ADR format, where to store them, when to create one, and examples based on past decisions. Use when making a significant technical decision that should be recorded for future maintainers.
Add a new MCP tool to the atlas-fs or atlas-rag server. Covers tool definition, handler function, parameter schema, and register call. Use when implementing a new feature that needs to be exposed as an MCP tool.
Build the portable RAG bundle: clone docs, chunk, embed, package tarball. Use when the task involves building a bundle locally (`atlas-build`), smoke testing a bundle (`atlas-smoke`), or adding a new publication.
Evaluate RAG quality: run Precision@10 and MRR against a bundle, interpret the scores, and compare CI-built vs locally-built bundles. Use when assessing bundle quality, comparing backends, or investigating a regressed search result.