pjandro/OmniRoute
1
0
Fork 0
mirror of https://github.com/diegosouzapw/OmniRoute.git synced 2026-09-20 22:02:19 +03:00
Code Issues Packages Projects Releases Wiki Activity
Files
d715190bb03da80da933d562129d8a76998eaa4d
OmniRoute/docs/i18n/ka/docs/ops/RELEASE_CHECKLIST.md
Diego Rodrigues de Sa e Souza b637350680 fix(docs): re-sync the 65 documentation mirror sets; section-level docs pipeline; drift gate blocking (#13940) 
1,104 mirrors rewritten over five passes of run-translation on the 22-source core set: the 14 sources edited since their translation, the 322 mirrors that were still English copies, and the frontmatter the old extractor leaked into the newer locales' bodies. The pipeline now caches per-`## `-section hashes and retranslates only changed sections, never reuses a section that is still English, rebuilds English-copy / leaked mirrors even when the source is unchanged, merges the state on save (parallel runs), and the drift gate (scoped to the core set) is blocking. Final audit: 0 stale, 0 English copies, 0 leaked frontmatter across 1,430 core mirrors.

⚠️ base-red inherited: #12732
2026-09-17 02:55:31 -03:00

54 KiB
Raw Blame History

Release Checklist (ქართული)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

ბოლოს განახლდა: 2026-08-28 — v3.8.51 გამარტივებული გამოშვების პროცესი, რომელიც ავტომატიზაციისთვის Claude Code-ის უნარებს იყენებს.

გამოშვებებს შორის რიგისა და ბრენჩის გამართულობა შეინარჩუნეთ: იხილეთ RELEASE_GREEN.md (/green-prs ოჯახი + npm run check:release-green + /babysit + ყოველღამეული შემოწმება). ამის პერიოდულად გაშვება — და განსაკუთრებით ამ საკონტროლო სიის შესრულებამდე — უზრუნველყოფს, რომ გამოშვების PR თავიდანვე გამართული იყოს.

მოკლედ

# 1. გაზარდეთ ვერსია + შექმენით CHANGELOG (უნარი)
/version-bump-cc patch    # ან minor/major

# 2. გაუშვით ხარისხის შემოწმება ლოკალურად
npm run check              # ლინტინგი + ტესტები
npm run test:coverage      # დაფარვის სრული შემოწმება (60/60/60/60)

# 3. ააგეთ და ჩაატარეთ სწრაფი შემოწმება
npm run build
npm run test:e2e           # არასავალდებულო, თუმცა რეკომენდებულია

# 4. შექმენით რელიზი (უნარი)
/generate-release-cc

# 5. განათავსეთ (უნარი)
/deploy-vps-both-cc        # ან akamai-cc / local-cc

# 6. შეაგროვეთ რელიზის მტკიცებულებები (უნარი)
/capture-release-evidences-cc

npm Trusted Publishing (ნაგულისხმევი v3.8.51-დან) — მოთხოვნისას ეტაპობრივი, სარეზერვოდ პირდაპირი

npm-publish.yml ნაგულისხმევად აქვეყნებს npm Trusted Publishing (OIDC)-ის მეშვეობით: stage-npm დავალება (github-hosted) GitHub-ის id-token-ს ცვლის მოკლევადიან npm ავტორიზაციის მონაცემზე მხოლოდ ამ გაშვებისთვის — რეპოზიტორიის საიდუმლოებებში ხანგრძლივი მოქმედების npm ტოკენისა და 2FA მოთხოვნის გარეშე, თან დართული provenance-ით. ეს არის npm-ის მიერ ახლა ნებადართული გვერდის ავლის გზა, რადგან 2FA-ის გამომტოვებელი ტოკენები უქმდება; იგი აღადგენს სრულად ავტომატურ პროცესს, რომელიც პროექტს v3.8.48-მდე ჰქონდა, და ამავდროულად ინარჩუნებს WS1.3 გარანტიას (გაჟონილი ტოკენი დამოუკიდებლად ვერ გამოაქვეყნებს — რადგან ტოკენი საერთოდ არ არსებობს).

ერთჯერადი გამართვა (მფლობელი): npmjs.com → package omniroute → Settings → Trusted Publisher → GitHub: owner diegosouzapw, repo OmniRoute, workflow npm-publish.yml (environment: none). სანამ ეს არ იარსებებს, ავტომატური ნაბიჯი ENEEDAUTH შეცდომით დასრულდება: ხელახლა გაუშვით publish_mode=staged-ით (ქვემოთ) ან direct-ით.

ეტაპობრივი გამოქვეყნება (მოთხოვნისას — publish_mode=staged)

npm-publish სამუშაო პროცესი პირდაპირ აღარ აქვეყნებს: იგი უშვებს შეფუთულ tarball-ს (check:pack-boot) და შემდეგ ასრულებს npm stage publish-ს — ზუსტად ეს ბაიტები თავსდება რეესტრში და მფლობელის დამტკიცებამდე დასაინსტალირებელი არ არის. ადამიანის 2FA ბარიერი მტკიცებულების მიღების შემდეგ გადავიდა და არა მის წინ.

მფლობელის პროცესი სამუშაო პროცესის წარმატებით დასრულების შემდეგ:

  1. npm stage list omniroute — იპოვეთ ეტაპის id (ის ასევე იბეჭდება სამუშაო პროცესის შეჯამებაში).
  2. გადაამოწმეთ ეტაპობრივად განთავსებული ბაიტები (რეკომენდებულია): npm stage download <id>, შემდეგ დააინსტალირეთ ჩამოტვირთული tarball დროებით prefix-ში და გაუშვით იგი (npm run check:pack-boot CI-ში იმავე pack→install→boot შემოწმებას ავტომატურად ასრულებს).
  3. npm stage approve <id> — 2FA მოთხოვნა თავად არის გამოქვეყნება. npm stage reject <id> მას გააუქმებს.
  4. გამოქვეყნების შემდგომი დამცავი შემოწმება: გამოქვეყნების შემდგომი ვერიფიკატორი (v3.8.49 გეგმის WS1.4) სუფთა კონტეინერში საჯარო რეესტრიდან აყენებს გამოქვეყნებულ ვერსიას და უშვებს მას.

საგანგებო სარეზერვო გზა: workflow_dispatch პარამეტრით publish_mode=direct აღადგენს ძველ, მყისიერ npm publish-ს (გამოიყენეთ მხოლოდ მაშინ, თუ თავად ეტაპობრივი პროცესი გაუმართავია; დააფიქსირეთ მიზეზი).

ერთჯერადი გამკაცრება (მფლობელი, npmjs.com): omniroute-ისთვის Trusted Publisher მხოლოდ ეტაპობრივ რეჟიმში გამართეთ, რათა გაჟონილმა ხანგრძლივი მოქმედების ტოკენმა პირდაპირ npm publish ვერსაიდან ვერ შეასრულოს — CI-ს მხოლოდ ეტაპობრივად განთავსება შეუძლია; გამოქვეყნება მხოლოდ მფლობელის 2FA-ს შეუძლია.

დაზიანებული არტეფაქტის სამოქმედო გეგმა (უცვლელი): ნაგულისხმევი რეაქციაა npm deprecate omniroute@<bad> "<reason> — use <fixed>" (რამდენიმე წუთი, შექცევადი); npm unpublish გამოიყენეთ მხოლოდ 72-საათიან/დამოკიდებული პაკეტების არქონის პერიოდში და არასოდეს პირველ ნაბიჯად. Docker: არასოდეს გადაწეროთ ვერსიის ტეგი — უკან დაბრუნება ნიშნავს latest-ის ბოლო გამართულ digest-ზე გადამისამართებას.

Docker Hub-ის latest (სავალდებულოა ყოველი სტაბილური SemVer გამოქვეყნებისას): docker-publish სამუშაო პროცესმა ტეგი უნდა მიანიჭოს როგორც X.Y.Z-ს, ისე — როდესაც should-promote-latest.sh დაადასტურებს, რომ ეს უმაღლესი სტაბილური SemVer-ია — :latest-ს, ერთი და იმავე digest-ით. დავალების დასრულების შემდეგ: Hub-ის latest digest უნდა ემთხვეოდეს ახალ SemVer digest-ს და last_updated უნდა იყოს განახლებული. არ დატოვოთ :latest ძველ build-ზე, როცა რელიზის შენიშვნები აღწერს შესწორებებს, რომლებიც მხოლოდ git-ში არსებობს. Compose-ის სწრაფი დაწყების კონფიგურაციები იყენებს :latest-ს; GitOps-მა კვლავ X.Y.Z უნდა დააფიქსიროს. იხილეთ Docker-ის რელიზის არხები და #10317.

Hotfix-ის სწრაფი ზოლი (ლეიბლი hotfix)

PR, რომელსაც მინიჭებული აქვს ლეიბლი hotfix, გამოტოვებს მძიმე CI მატრიცას (9-shard E2E, coverage ratchet, quality-gate, quality-extended) და ინარჩუნებს სწრაფ, მაღალი სიგნალის მქონე შემოწმებებს: build, unit shards, integration, vitest, lint/typecheck, docs-sync, check:pack-artifact და tarball-ის გაშვების smoke-ტესტს (check:pack-boot). მიზანი: ~33min-ის ნაცვლად ≤15min-ში მწვანე სტატუსის მიღება.

შესვლის პოლიტიკა — ოთხივე მოთხოვნა სავალდებულოა (Chromium/VS Code/Node-ის საგანგებო ზოლების მოდელით):

  1. სიმძიმე: production გატეხილია — გამოქვეყნებული არტეფაქტი გაშვებისას ავარიულად ითიშება / საჭიროა უსაფრთხოების შესწორება / რელიზის ყველა მომხმარებელი დაზარალებულია. „მნიშვნელოვანი“ არ ნიშნავს „გატეხილს“.
  2. უფლებამოსილება: hotfix ლეიბლს მხოლოდ რეპოზიტორიის მფლობელი ანიჭებს. ლეიბლი თავად არის დამტკიცება — კამპანიურ PR-ზე მისი თვითნებურად გამოყენება დაუშვებელია.
  3. მტკიცებულება: PR-ის აღწერა შეიცავს ბმულს წინა სრულად მწვანე მძიმე გაშვებაზე (ტესტების ნაკრები, რომელსაც გამოტოვებული jobs ხელახლა გადაამოწმებდა), ასევე თავად შესწორების თავდაპირველად ჩავარდნილ და შემდეგ წარმატებულ ტესტზე.
  4. მოცულობა: მხოლოდ cherry-pick — მინიმალური შესწორება, refactor-ების და თანმხლები ცვლილებების გარეშე.

გამოტოვებული coverage/ratchet ზედაპირი ხელახლა მოწმდება release branch-ზე მომდევნო სრული გაშვებით (უწყვეტი release-green) — ეს ზოლი გამოტოვებს მხოლოდ ლოდინს და არასდროს — ვალიდაციას. მხოლოდ ტესტების შემცველი diff-ები (ყველა ფაილი tests/-ში, არცერთი tests/e2e/-ში) E2E მატრიცას ავტომატურად, ყოველგვარი ლეიბლის გარეშე გამოტოვებს.

დეტალური საკონტროლო სია

რელიზამდე

  • ამ რელიზისთვის განკუთვნილი ყველა PR გაერთიანებულია release/vX.Y.0-ში
  • ამ ვერსიის ყველა ღია Linear/issue ელემენტი დახურულია ან გადატანილია შემდეგ milestone-ზე
  • CI მწვანეა release/vX.Y.0 branch-ზე
  • კოდში არ არის TODO(release) მარკერები: grep -r "TODO(release)" src/ open-sse/
  • Docker-ის საბაზო image განახლებულია (ამჟამად node:24.15.0-trixie-slim)

ვერსია და ცვლილებების ჟურნალი

  • გაუშვით /version-bump-cc <patch|minor|major> (Claude Code skill)
    • ზრდის ვერსიას package.json-სა და electron/package.json-ში
    • თავიდან აგენერირებს CHANGELOG.md-ს ბოლო tag-ის შემდეგ შესრულებული git commit-ებიდან
    • აახლებს README.md-ის badge-ებს
  • ხელით გადახედეთ CHANGELOG.md-ს და საჭიროების შემთხვევაში გაასუფთავეთ commit-ის შეტყობინებები
  • დარწმუნდით, რომ CHANGELOG.md-ის უახლესი semver სექცია ემთხვევა package.json-ის ვერსიას
  • მომავალი სამუშაოებისთვის ## [Unreleased] დატოვეთ ცვლილებების ჟურნალის პირველ სექციად
  • განაახლეთ docs/openapi.yaml → info.version უნდა ემთხვეოდეს package.json-ის ვერსიას

კოდის ხარისხი

  • npm run lint — 0 შეცდომა (გაფრთხილებები უკვე არსებობდა)
  • npm run typecheck:core — სუფთა
  • npm run typecheck:noimplicit:core — სუფთა (მკაცრი)
  • npm run check:cycles — ციკლური დამოკიდებულებების გარეშე
  • npm run check:any-budget:t11 — ბიუჯეტის ფარგლებში
  • npm run check:route-validation:t06 — სუფთა
  • npm run check:node-runtime — მხარდაჭერილი runtime-ის მინიმალური ზღვარი დაკმაყოფილებულია (>=22.22.2 <23, >=24.0.0 <27, SUPPORTED_NODE_RANGE-ის მიხედვით src/shared/utils/nodeRuntimeSupport.ts-ში; შესაბამისობაშია package.json-ის engines-თან)

ტესტირება

  • npm run test:unit — წარმატებით დასრულება
  • npm run test:vitest — წარმატებით დასრულება (MCP server, autoCombo, cache)
  • npm run test:coverage — 60/60/60/60 ზღვარი დაკმაყოფილებულია (statements/lines/functions/branches)
  • npm run test:integration — წარმატებით დასრულება (თუ ცვლილებები ეხება DB-ს / handlers-ს)
  • npm run test:combo:matrix — წარმატებით დასრულება (combo სტრატეგიების მატრიცა: დეტერმინისტულად ადასტურებს 19-ვე საჯარო routing სტრატეგიის შერჩევის გადაწყვეტილებებს; გაუშვით combo routing-ის, strategy resolution-ის ან fallback ლოგიკის ცვლილებისას)
  • RUN_COMBO_LIVE=1 npm run test:combo:live — არასავალდებულო/ხელით გასაშვები (საკონტროლო პირობით დაცული რეალურ upstream-ზე smoke-ტესტი; იყენებს მხოლოდ წასაკითხ DB snapshot-ს VPS-იდან root@192.168.0.15; მიმართავს რეალურ providers-ს, ხარჯავს კრედიტებს; არასდროს ეშვება CI-ში; საკონტროლო პირობის გარეშე სუფთად გამოიტოვება)
  • npm run test:combo:live:vps — არასავალდებულო/ხელით გასაშვები (Phase-3 VPS-ის live smoke-ტესტი: 7 HTTP სცენარი live .15 server-ის მიმართ უბრალო Node ESM-ით; საჭიროებს ssh root@192.168.0.15-ს; ქმნის/შლის მხოლოდ __live_test__* combo-ებს; მიმართავს რეალურ providers-ს; არასდროს ეშვება CI-ში)
  • npm run test:e2e — წარმატებით დასრულება (UI ცვლილებები)
  • npm run test:protocols:e2e — წარმატებით დასრულება (MCP/A2A ცვლილებები)
  • npm run test:ecosystem — წარმატებით დასრულება

Hooks (შემოწმებულია Husky-ით)

Husky hooks განთავსებულია .husky/-ში და ავტომატურად ეშვება git ოპერაციებისას.

  • pre-commit: npx lint-staged + node scripts/check/check-docs-sync.mjs + npm run check:any-budget:t11
  • pre-push: სწრაფი დეტერმინისტული შემოწმებები — npm run check:any-budget:t11 && npm run check:tracked-artifacts (გააქტიურდა 2026-06-13). განზრახ არ მოიცავს test:unit-ს (ნელია; დაფარულია CI-ის test-unit job-ით).
    • release branch-ების push-მდე ხელით გაუშვით npm run test:unit.

თუ hook ჩავარდა: გამოასწორეთ ძირეული პრობლემა და გვერდი არ აუაროთ --no-verify-ით.

Conventional Commits

რელიზში შესატანი ყველა commit უნდა შეესაბამებოდეს type(scope): subject ფორმატს.

დაშვებული ტიპები: feat, fix, refactor, docs, test, chore, perf, style, ci

დაშვებული scope-ები: db, sse, oauth, dashboard, api, cli, docker, ci, mcp, a2a, memory, skills, cloud-agent, guardrails, compression, auto-combo, resilience, providers, executors, translator, domain, authz

უკუთავსებადობის დამრღვევი ცვლილებები: დაამატეთ BREAKING CHANGE: footer ან ! scope-ის შემდეგ (მაგ. feat(api)!: drop /v0).

დოკუმენტაცია

  • npm run check:docs-sync წარმატებით სრულდება (ავტომატურად ეშვება pre-commit-ის მიერ)
  • npm run check:docs-all წარმატებით სრულდება (გამაერთიანებელი: docs-sync + docs-counts + env-doc-sync + deprecated-versions + doc-links)
  • npm run check:env-doc-sync სრულდება 0 კოდით — კოდს ↔ .env.example-ს ↔ docs/reference/ENVIRONMENT.md-ს შორის გარემოს კონტრაქტი უცვლელია
  • npm run check:doc-links სრულდება 0 კოდით — რესტრუქტურიზაციის შემდეგ შიდა markdown-მითითებები არ არის გატეხილი
  • docs/architecture/ARCHITECTURE.md გადამოწმებულია საცავის/შესრულების გარემოს აცდენებზე
  • docs/guides/TROUBLESHOOTING.md გადამოწმებულია გარემოს ცვლადებისა და ოპერაციული აცდენების კუთხით
  • თუ .env.example შეიცვალა: docs/reference/ENVIRONMENT.md განახლებულია
  • თუ ახალ ფუნქციას აქვს UI: ის მოხსენიებულია docs/guides/USER_GUIDE.md-ში
  • თუ ახალ ფუნქციას აქვს API: განახლებულია docs/reference/API_REFERENCE.md + docs/openapi.yaml
  • თუ ახალი ფუნქცია მოდულია: არსებობს მისთვის განკუთვნილი docs/<MODULE>.md
  • თუ ცვლილება უკუთავსებადობას არღვევს: docs/guides/TROUBLESHOOTING.md შეიცავს მიგრაციის შენიშვნას

i18n

  • npm run i18n:check სრულდება 0 კოდით — თარგმანის მდგომარეობა (.i18n-state.json) სინქრონიზებულია საწყის დოკუმენტაციასთან (მკაცრ რეჟიმში აცდენილი წყაროები არ არის; გაფრთხილების რეჟიმის შეტყობინებები დასაშვებია ბოლო წუთის დოკუმენტაციის მცირე შესწორებებისთვის, თუმცა თეგის შექმნამდე შედეგი 0 უნდა იყოს)
  • npm run i18n:check-ui-coverage სრულდება 0 კოდით — თითოეული UI ლოკალის დაფარვა მინიმუმ 80%-ია
  • npm run i18n:sync-ui:dry-ის ანგარიშში 42-ვე ლოკალში 0 გამოტოვებული გასაღებია
  • თუ საწყისი ინგლისური დოკუმენტაცია შეიცვალა, თეგის შექმნამდე გაუშვით npm run i18n:run (.env-ში მოითხოვს OMNIROUTE_TRANSLATION_API_KEY-ს)
  • თუ თარგმანებში ცვლილებები მცირეა, მათი შეტანა შეიძლება შემდეგ რელიზამდე გადაიდოს (აღრიცხეთ CHANGELOG-ში)

მონაცემთა ბაზის მიგრაციები

  • თუ src/lib/db/migrations/ შეიცავს ახალ ფაილებს:
    • თითოეული მიგრაცია იდემპოტენტურია (CREATE TABLE IF NOT EXISTS და ა.შ.)
    • მიგრაციები მოქცეულია ტრანზაქციებში
    • დანომრილია სწორად (მიმდევრობაში გამოტოვებების გარეშე)
  • შეამოწმეთ ახალ ინსტალაციაზე: წაშალეთ ~/.omniroute/omniroute.db და გაუშვით npm run dev
  • შეამოწმეთ არსებულ ინსტალაციაზე: შექმენით DB-ის სარეზერვო ასლი, გაუშვით მიგრაცია და გადაამოწმეთ სქემა
  • თუ მიგრაცია ცხრილებს თავიდან წერს, WAL ფაილები (-wal, -shm) სწორად უნდა დამუშავდეს

პროვაიდერების კატალოგი (Zod-ით ვალიდირებული)

  • src/shared/constants/providers.ts-ის Zod სქემა ჩატვირთვისას ვალიდურია
    • ყველა პროვაიდერს აქვს სავალდებულო ველები (id, label, kind და ა.შ.)
    • ახალი უფასო პროვაიდერებისთვის მითითებულია freeNote
    • OAuth პროვაიდერების oauthConfig რეგისტრირებულია src/lib/oauth/constants/oauth.ts-ში
  • თუ დაემატა ახალი პროვაიდერი: შესაბამისი შემსრულებელი არსებობს open-sse/executors/-ში
  • თუ ფორმატი OpenAI-ს არ შეესაბამება: მთარგმნელი არსებობს open-sse/translator/-ში
  • მოდელები რეგისტრირებულია open-sse/config/providerRegistry.ts-ში
  • tests/unit/-ში არსებული მოდულური ტესტები ფარავს პროვაიდერების კლასიფიკაციასა და მარშრუტიზაციას

დესკტოპი (Electron)

თუ electron/ შეიცვალა:

  • npm run electron:smoke:packaged წარმატებით სრულდება
  • აგებები შემოწმებულია მინიმუმ ერთ-ერთისთვის: :win, :mac, :linux
  • კოდის ხელმოწერის სერტიფიკატებს ვადა არ გასვლიათ (თუ ხელმოწერა გამოიყენება)
  • electron/package.json-ის ვერსია ემთხვევა ძირითადი package.json-ის ვერსიას
  • ავტომატური განახლების არხის მაჩვენებელი განახლებულია, თუ რელიზი stable არხისთვისაა

აგების განლაგება

რეპოზიტორია იყენებს შედეგების სამ განსხვავებულ დირექტორიას — ისინი არასოდეს აურიოთ:

დირექტორია დანიშნულება კონტროლდება?
src/ აპლიკაციის საწყისი კოდი (TypeScript / TSX) დიახ
.build/ აგების შუალედური შედეგები — next build-ის შედეგი (distDir) არა (gitignored)
dist/ გასავრცელებელი npm პაკეტი — აწყობილია assembleStandalone-ის მიერ არა (gitignored)

ოპერატორის შენიშვნა: დისტანციური VPS-ის ასლის დირექტორიად კვლავ რჩება /usr/lib/node_modules/omniroute/app/. შეიცვალა მხოლოდ რეპოზიტორიაში არსებული აგების შედეგის მდებარეობა (app/ → dist/). განთავსების უნარები rsync-ის მეშვეობით dist/-ის შიგთავსს დისტანციურ app/ დირექტორიაში აკოპირებს — VPS-ის გზების შეცვლა საჭირო არ არის.

ერთჯერადი აგების პროცესი:

npm run build:release
  └─ rm -rf .build dist          (გასუფთავება)
  └─ next build → .build/next/   (შუალედური შედეგები)
  └─ assembleStandalone          (აკოპირებს standalone + static + public + natives → dist/)
  └─ writes dist/BUILD_SHA       (HEAD საკონტროლო მაჩვენებელი)

განთავსებისთვის ნუ გაუშვებთ npm run build-ს და შემდეგ ცალკე npm run build:cli-ს — გამოიყენეთ npm run build:release, რომელიც ერთი ბრძანებით ასრულებს სუფთა ხელახალ აგებას და საკონტროლო მაჩვენებლის შექმნას.

არტეფაქტის ვალიდაცია

  • npm run build:release წარმატებით სრულდება და dist/BUILD_SHA == git rev-parse --short HEAD
  • npm run check:pack-artifact სუფთაა — არ შეიცავს app.__qa_backup-ს, scripts/scratch-ს, package-lock.json-ს ან სხვა ლოკალურ ნარჩენებს
  • აგების შემდეგ dist/server.js არსებობს

თეგის შექმნა და რელიზი

  • გაუშვით /generate-release-cc (Claude Code-ის უნარი):
    • ქმნის თეგს vX.Y.Z
    • ატვირთავს თეგსა და ბრენჩს
    • ხსნის GitHub Release-ს ცვლილებების ჟურნალის ტექსტით
    • ურთავს Electron-ის ინსტალატორებს (თუ აგებულია)
  • ან ხელით: 
    git tag -a vX.Y.Z -m "Release vX.Y.Z"
git push origin vX.Y.Z
gh release create vX.Y.Z --notes-from-tag

განთავსება

განთავსების უნარები იყენებს მსუბუქ rsync პროცესს — npm pack და npm i -g არ გამოიყენება:

  • გამოიყენეთ სამიზნის შესაბამისი განთავსების უნარი:
    • /deploy-vps-local-cc — ლოკალური VPS (192.168.0.15)
    • /deploy-vps-akamai-cc — Akamai VPS (69.164.221.35)
    • /deploy-vps-both-cc — ორივე
  • განთავსებამდე დაადასტურეთ, რომ dist/BUILD_SHA == git rev-parse --short HEAD
  • აგება უნდა შესრულდეს იქ, სადაც node_modules რეალურია (ძირითად სამუშაო ასლში ან npm ci-ით მომზადებულ worktree-ში — და არა სიმბოლური ბმით დაკავშირებულ worktree-ში)
  • ჩაატარეთ განთავსებული ინსტანციის სწრაფი ტესტი:
    • გახსენით /dashboard/health → შეამოწმეთ, რომ ვერსიის სტრიქონი რელიზს ემთხვევა
    • ცნობილ პროვაიდერთან გაგზავნეთ /v1/chat/completions მოთხოვნა
    • გადაამოწმეთ, რომ /api/monitoring/health აბრუნებს CLOSED მდგომარეობის circuit breaker-ებს
    • დაადასტურეთ, რომ MCP ტრანსპორტები პასუხობს (/mcp HTTP, /mcp-sse SSE)

რელიზის შემდეგ

  • გაუშვით /capture-release-evidences-cc (Claude Code-ის skill)
    • იღებს ახალი ფუნქციების WebP ეკრანის ანაბეჭდებს/ჩანაწერებს
    • ამაგრებს რელიზის შენიშვნებზე / ბლოგპოსტზე
  • განაახლეთ GitHub Discussions / Discord რელიზის შესახებ განცხადებით
  • გახსენით milestone შემდეგი ვერსიისთვის
  • თუ კრიტიკულია: დაამაგრეთ განხილვა ან გამოაქვეყნეთ news.json-ში აპშიდა ბანერისთვის

Radar-ის საჯარო გაშვების საკონტროლო ეტაპი

Radar-ის განცხადება განზრახ არის დაკომიტებული active: false მნიშვნელობით. მისი გააქტიურება ცალკე ცვლილებაა, რომელიც ქვემოთ ჩამოთვლილი თითოეული პუნქტის მტკიცებულებით დადასტურების შემდეგ უნდა განხორციელდეს:

  • ყველა ერთმანეთზე დაფუძნებული Radar PR გაერთიანებულია და release-tip CI წარმატებით დასრულებულია
  • განათავსეთ და სწრაფად შეამოწმეთ OSS Radar-ის მარშრუტები, როცა RADAR_ENABLED ნაგულისხმევად კვლავ გამორთულია
  • სწრაფად შეამოწმეთ GET /planos, /termos, /privacidade და /reembolso მითითებულ Radar ჰოსტზე
  • კერძო სერვისში დააფიქსირეთ ოპერატორის ვინაობა/საკონტაქტო ინფორმაცია/მისამართი და მფლობელის მიერ დამტკიცებული იურიდიული შემოწმება
  • შეამოწმეთ Stripe Checkout და ხელმოწერილი webhook მხოლოდ სატესტო რეჟიმში
  • შეამოწმეთ ერთი დაშიფრული ტრანზაქციული ელფოსტის მიწოდება დამტკიცებული გამომგზავნით/დომენით
  • დაადასტურეთ სარეზერვო ასლიდან აღდგენა და ერთი ზედამხედველობით ჩატარებული, ბიუჯეტით შეზღუდული კვლევითი გაშვება
  • შემოწირულობის მტკიცებულების მიღებამდე დაამტკიცეთ BRL/PIX-ის შემოწმების პოლიტიკა
  • საჯარო Checkout ჩართეთ მხოლოდ წინა საკონტროლო ეტაპების გავლის შემდეგ, შემდეგ კი გაააქტიურეთ ახალი news.json ID
  • გადაამოწმეთ, რომ Home ბანერი ლოკალიზებულ ტექსტს იყენებს და ახალი ID ხელახლა გამოჩნდება ძველი ID-ის დახურვის შემდეგ

ჩაშენებული სერვისების smoke-ტესტი (v3.8.4+)

ჩაშენებულ სერვისებში ცვლილებების შემცველი ნებისმიერი რელიზის გამოშვებამდე გადაამოწმეთ:

სუფთა DB-ით გაშვება (ავლენს მიგრაციების კონფლიქტებს — დაემატა v3.8.4-ის hotfix-ის შემდეგ)

  • DATA_DIR=$(mktemp -d) npm start & — გაშვებას დაელოდეთ 10 წმ
  • curl -s http://127.0.0.1:20128/api/services/9router/status | jq '.tool' აბრუნებს "9router"-ს (არა 404-ს, არა 500-ს). ადასტურებს, რომ მიგრაცია 071_services.sql გამოყენებულია და ჩანაწერი დამატებულია.
  • sqlite3 $DATA_DIR/storage.sqlite "PRAGMA table_info(version_manager);" | grep -E "provider_expose|logs_buffer_path|last_sync_at" აბრუნებს 3 სტრიქონს.
  • sqlite3 $DATA_DIR/storage.sqlite "PRAGMA table_info(webhooks);" | grep -E "kind|metadata_encrypted" აბრუნებს 2 სტრიქონს (ადასტურებს, რომ 070_webhooks_kind_metadata.sql გამოყენებულია).
  • node --import tsx/esm --test tests/unit/db/no-migration-collisions.test.ts წარმატებით სრულდება — იცავს მომავალში კონფლიქტების წარმოქმნისგან.

9Router

  • POST /api/services/9router/install 2 წუთზე ნაკლებ დროში აბრუნებს 200-ს და installedVersion-ს
  • POST /api/services/9router/start 30 წამზე ნაკლებ დროში აბრუნებს 200-ს და state: "running"-ს
  • GET /api/services/9router/status იტყობინება health: "healthy"-ს
  • POST /v1/chat/completions მოთხოვნა "model": "9router/auto/..."-ით აბრუნებს 200-ს (9Router-ის გავლით მარშრუტიზაციის სრული შემოწმება)
  • GET /dashboard/providers/services/9router/embed/dashboard პროქსის შიგნით ასახავს 9Router-ის მშობლიურ UI-ს (პირდაპირი 127.0.0.1:port iframe-ის გარეშე)
  • POST /api/services/9router/rotate-key აბრუნებს { keyRotated: true }-ს და სერვისი უპრობლემოდ იტვირთება ხელახლა
  • POST /api/services/9router/stop აბრუნებს 200-ს და state: "stopped"-ს
  • GET /api/services/9router/logs?tail=50 აბრუნებს SSE ნაკადს snapshot მოვლენით, რომელიც ბოლო სტრიქონებს შეიცავს
  • ისეთ გარემოში ინსტალაცია, სადაც PATH-ში npm არ არის, აბრუნებს 500-ს გასაგები შეცდომის შეტყობინებით (stack trace-ის გარეშე)

CLIProxyAPI

  • POST /api/services/cliproxy/install 2 წუთზე ნაკლებ დროში აბრუნებს 200-ს
  • POST /api/services/cliproxy/start 30 წამზე ნაკლებ დროში აბრუნებს 200-ს და state: "running"-ს
  • GET /api/services/cliproxy/status იტყობინება health: "healthy"-ს
  • POST /api/services/cliproxy/stop აბრუნებს 200-ს და state: "stopped"-ს
  • GET /api/services/cliproxy/logs?tail=50 აბრუნებს SSE ნაკადს

უსაფრთხოების რეგრესია

  • curl -H "X-Forwarded-For: 1.2.3.4" http://localhost:20128/api/services/9router/start აბრუნებს 403 LOCAL_ONLY-ს
  • curl -H "X-Forwarded-For: 1.2.3.4" http://localhost:20128/api/services/cliproxy/start აბრუნებს 403 LOCAL_ONLY-ს
  • /api/services/*-დან მიღებული შეცდომის პასუხები არ შეიცავს err.stack-ს ან ფაილების აბსოლუტურ ბილიკებს

v3.8.0+-ის შემოწმებები

ნებისმიერი v3.8.x რელიზის გამოშვებამდე გადაამოწმეთ შემდეგი დამატებითი პუნქტები:

  • omniroute --tray იშვება macOS-ზე (systray2 დაინსტალირებულია ~/.omniroute/runtime/-ში)
  • omniroute --tray იშვება Linux-ზე (საჭიროებს DISPLAY-ს; თუ ის დაყენებული არ არის, შეცდომა სათანადოდ მუშავდება)
  • omniroute --tray იშვება Windows-ზე (PowerShell NotifyIcon, დამატებითი ბინარული ფაილების გარეშე)
  • omniroute config tray enable ქმნის ავტომატური გაშვების ჩანაწერს; გამორთვა მას შლის
  • npm install -g omniroute@<this-version> postinstall-ს ფატალური დასრულების გარეშე ასრულებს
  • განახლების პროცესი ინარჩუნებს არასავალდებულო დამოკიდებულებებს: omniroute update --apply და ავტომატური განახლების მექანიზმი უშვებენ npm install -g … --include=optional-ს, რათა optionalDependencies (better-sqlite3, keytar, tls-client და llmlingua SLM სტეკი: @atjsh/llmlingua-2@2.0.5, js-tiktoken) განახლების შემდეგაც შენარჩუნდეს. ultra modelPath SLM დონეს ასევე სჭირდება tinybert მოდელი, რომელიც პირველი გამოყენებისას ავტომატურად ჩამოიტვირთება ${DATA_DIR}/models/llmlingua-ში. შემდეგ postinstall (scripts/build/colocateOptionals.mjs) SLM-ის არასავალდებულო დამოკიდებულებების სრულ ნაკრებს dist/node_modules-ში ათავსებს, რათა worker-მა @huggingface/transformers ^4.2.0-ის მხოლოდ ერთი ეგზემპლარი ამოიცნოს — დამოუკიდებელი trace მხოლოდ transformers-ს აერთიანებს და არა დინამიკურად იმპორტირებულ არასავალდებულო დამოკიდებულებებს, ამიტომ ამის გარეშე worker-ი llmlingua-2-ს ძირეული transformers-ით ჩატვირთავდა და SLM დონე შეუმჩნევლად fail-open რეჟიმში გადავიდოდა.
  • omniroute status მუშაობს .env-ის გარეშე (CLI token-ის ბილიკი, მხოლოდ loopback)
  • curl http://localhost:20128/api/shutdown აბრუნებს 401-ს (ყოველთვის დაცული მარშრუტი)
  • curl -H "host: evil.com" http://localhost:20128/api/mcp/sse აბრუნებს 401-ს (loopback-ის დამცავი მექანიზმი)
  • პირველი გაშვებისას SQLite runtime განისაზღვრება, როგორც bundled (ჩაშენებული ბინარული ფაილი მოქმედია შესაბამისი პლატფორმისთვის)
  • node_modules/better-sqlite3-ის წაშლისას SQLite runtime სათადარიგო ვარიანტად runtime-ზე გადადის
  • Smart MCP ფილტრი კუმშავს რეალურ playwright-mcp browser_snapshot გამომავალს (≥50%-იანი შემცირება)
  • ათივე skills/omniroute*/SKILL.md ფაილი საჯაროდ ხელმისაწვდომია raw GitHub URL-ის მეშვეობით
  • ახალი დაყენებისას საწყისი კონფიგურაციის ოსტატი აჩვენებს დონეების მიმოხილვის ნაბიჯს „როგორ მუშაობს“
  • მთავარ dashboard-ზე დონეების დაფარვის ვიჯეტი აჩვენებს კონფიგურირებული/აქტიური ერთეულების რაოდენობებს

უკან დაბრუნება

თუ რელიზს კრიტიკული პრობლემა აქვს:

  1. gh release edit vX.Y.Z --prerelease (მონიშნავს, რომ უახლესი არ არის)
  2. git tag -d vX.Y.Z && git push --delete origin vX.Y.Z (მხოლოდ იმ შემთხვევაში, თუ მომხმარებლებს ჯერ არ დაუწყიათ მისი გამოყენება)
  3. ან: ცხელი შესწორება release/vX.Y.0-ზე → პატჩ-რელიზი vX.Y.(Z+1)
  4. დაუყოვნებლივ აცნობეთ GitHub Discussions-სა და Discord-ში

მკაცრი წესები

  • არასოდეს შეიტანოთ კომიტი პირდაპირ main-ში
  • არასოდეს გამოიყენოთ git push --force main ან release/* ბრენჩებზე
  • არასოდეს გამოტოვოთ Husky-ის ჰუკები (--no-verify)
  • არასოდეს შეიტანოთ კომიტში საიდუმლოები, ავტორიზაციის მონაცემები ან .env ფაილები
  • დაფარვა უნდა დარჩეს ≥60/60/60/60 (ინსტრუქციები/სტრიქონები/ფუნქციები/ბრენჩები)
  • src/, open-sse/, electron/ ან bin/-ში საწარმოო კოდის შეცვლისას ყოველთვის დაამატეთ ან განაახლეთ ტესტები

სინქრონიზაციის ავტომატური შემოწმება

PR-ის გახსნამდე ლოკალურად გაუშვით დოკუმენტაციის სინქრონიზაციის დამცავი შემოწმება:

npm run check:docs-sync

CI ასევე უშვებს ამ შემოწმებას .github/workflows/ci.yml-ში (ლინტინგის დავალება).

Reference in New Issue View Git Blame Copy Permalink