Skip to content

Enzonic CI

သင့် GitHub repository များအတွက် CI, Enzonic runner များပေါ်တွင်။

Enzonic CI သည် push နှင့် pull request တိုင်းတွင် သင့် test နှင့် build များကို run ပေးပြီး job တစ်ခုစီသည် Enzonic လည်ပတ်သော Linux runner များပေါ်ရှိ ကိုယ်ပိုင် sandbox တွင် run ပါသည်။ Live log များ၊ dependency cache များနှင့် artifact များသည် Deploy နှင့် Databases နှင့် အကောင့်နှင့် အစီအစဉ်တူတွင် ရှိသည်။

အစီအစဉ်တိုင်းတွင် ပါဝင်သည်၊ Free ပါ ပါဝင်သည်။ CI မိနစ်များ၊ တပြိုင်နက်တည်း jobs နှင့် သိမ်းဆည်းချိန်တို့သည် သင်၏ အစီအစဉ်နှင့်အတူ ပါလာသည်။

Enzonic CI: repository သုံးခု၏ pipeline များ၊ ၎င်းတို့၏ နောက်ဆုံး run များနှင့် ရှင်းပြထားသော configuration ပြဿနာ

တူညီသော workflow ဖြင့် GitHub Actions ထက် ပိုမြန်သည်

workflow တစ်ခုကို ပလက်ဖောင်းနှစ်ခုလုံးတွင် လည်ပတ်သည်: npm ci နှင့် vitest suite ပါသော Node job နှင့် go test ပါသော Go job။ နည်းလေ ပိုကောင်းလေ။

အဆင့်Enzonic CIGitHub Actions
push မှ job အားလုံး ပြီးသည်အထိ လည်ပတ်မှု အပြည့် (warm caches)37 s
ကုဒ်ဆွဲယူခြင်း1 s
warm cache ဖြင့် npm ci3 s
cold caches ဖြင့် go test20 s
Go job၊ စမှ ဆုံးအထိ (warm caches)11 s

ကျွန်ုပ်တို့ နှေးသော နေရာ: lockfile ပြောင်းပြီးနောက် ပထမ npm ci သည် 6.8 s ကြာပြီး GitHub တွင် 4 s ကြာသည်၊ အကြောင်းမှာ npm ထုတ်ယူသော ဖိုင်တိုင်းသည် job ၏ sandbox ကို ဖြတ်သွားရသောကြောင့်ဖြစ်သည်။ တူညီသော lockfile ဖြင့် နောက်ပိုင်း လည်ပတ်မှုတိုင်းသည် 0.09 s ကြာသည်။

November 1, 2026 တွင် ပလက်ဖောင်းနှစ်ခုစလုံးတွင် တူညီသော .github/workflows/ci.yml ကို အသုံးပြု၍ တိုင်းတာခဲ့သည် (GitHub ubuntu-latest ပေါ်တွင်)၊ benchmark repository တစ်ခုတွင်။ 3 ကြိမ် လည်ပတ်မှု၏ median၊ စက္ကန့်ဖြင့်; warm လည်ပတ်မှုများတွင် ပလက်ဖောင်းတစ်ခုစီ၏ caches ရှိနေပြီးဖြစ်သည်။ GitHub ၏ cold ကိန်းဂဏန်းများသည် ပထမဆုံး လည်ပတ်မှု တစ်ကြိမ်မှ ဖြစ်သည်။

သင် ရင်းနှီးပြီးသား configuration

.enzonic/ci.yml ကို ရေးပါ၊ သို့မဟုတ် သင့် GitHub Actions workflow များကို ဆက်သုံးပါ: Enzonic CI သည် .github/workflows ၏ ထောက်ပံ့ထားသော အပိုင်းကို run ပြီး မပြုလုပ်နိုင်သည်များကို အကြောင်းကြားပါသည်၊ ဥပမာ မထောက်ပံ့သော action များ၊ Windows သို့မဟုတ် macOS runner များနှင့် ပြန်သုံးနိုင်သော workflow များ၊ မက်ဆေ့ချ်တစ်ခုဖြင့်။

run ကို စတင်စေသည့်အရာ

  • Push နှင့် tag များ
  • Pull request များ
  • အချိန်ဇယားများ
  • console မှ manual run များနှင့် API မှ စတင်သော run များ

Job များကို Linux runner များပေါ်တွင် run ပါသည်။ Job တစ်ခုစီသည် ကိုယ်ပိုင် gVisor sandbox ကို ရရှိပြီး private network များသို့ ဝင်ရောက်ခွင့်မရှိပါ။

.enzonic/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    image: node:22-bookworm-slim
    services:
      postgres:
        image: postgres:17-alpine
        env:
          POSTGRES_PASSWORD: postgres
    env:
      DATABASE_URL: postgres://postgres:postgres@postgres:5432/postgres
    steps:
      - name: Install
        run: npm ci
      - name: Test
        run: npm test

ဥပမာတစ်ခု။ docs ရှိ CI reference တွင် ထောက်ပံ့သော key နှင့် action အားလုံးကို စာရင်းပြုထားသည်။

Push နှင့် pull request အားလုံး စာရင်းတစ်ခုတည်းတွင်

ချိတ်ဆက်ထားသော repository အားလုံး၏ run များကို status၊ event၊ branch၊ commit နှင့် ကြာချိန်တို့ဖြင့် ပြသသည်။ တစ်စုံတစ်ခု run နေစဉ် စာရင်းသည် အချိန်နှင့်တပြေးညီ ပြောင်းလဲနေပြီး run တစ်ခုစီသည် GitHub တွင် check တစ်ခုကို အစီရင်ခံသည်။

Enzonic CI: pipeline တစ်ခုစီ၏ run များကို status၊ branch၊ commit နှင့် ကြာချိန်တို့ဖြင့်

၎င်း လုပ်ဆောင်ပုံ

Matrix build များနှင့် job လိုအပ်ချက်များ
အလုပ်ကို job များအဖြစ် ခွဲပါ၊ matrix ဖြင့် ဖြန့်ပါ၊ needs ဖြင့် job များကို စီပါ။
Service container များ
Job ဘေးတွင် Postgres သို့မဟုတ် အခြား service တစ်ခုကို စတင်ပါ; run ကြာသည်အထိ ၎င်းသည် job ၏ network သို့ ပါဝင်သည်။
Job တစ်ခုလျှင် sandbox တစ်ခု
Job တစ်ခုစီသည် ကိုယ်ပိုင် network ပေါ်ရှိ ကိုယ်ပိုင် gVisor sandbox တွင် run ပြီး private network များသို့ ဝင်ရောက်ခွင့်မရှိပါ။
တိုက်ရိုက် logs နှင့် artifacts
အဆင့်တစ်ခုစီ run နေစဉ် လိုက်ကြည့်ပါ၊ မအောင်မြင်သော jobs များကို ပြန် run ပါ၊ သင့်အစီအစဉ်က သိမ်းထားသရွေ့ artifacts များကို ဒေါင်းလုဒ်လုပ်ပါ။
Fork မှ လုံခြုံသော pull request များ
Fork မှ pull request များအတွက် run များသည် မူလအနေဖြင့် secret မရရှိပါ။
မအောင်မြင်သော job များအတွက် ပြင်ဆင်ချက်များ
Enzonic ၏ assistant ဖြစ်သော Enzica သည် မအောင်မြင်သော job ၏ log များကို ဖတ်ပြီး ပြင်ဆင်ချက် အကြံပြုနိုင်ပါသည်၊ ပြောင်းလဲမှု မလုပ်မီ သင် ပြန်စစ်ပါ။

Dependency cache များ

Cache များကို အစီအစဉ်၏ cache အရွယ်အစားအတွင်း repository တစ်ခုစီအတွက် သိမ်းထားသည်။

  • npm
  • pnpm
  • Yarn
  • Bun
  • pip
  • Go
  • Cargo
  • Maven
  • Gradle

အစီအစဉ်အလိုက် CI ကန့်သတ်ချက်များ

CI မိနစ်များသည် လစဉ် ပြန်စတင်ပြီး ပြီးဆုံးသွားသော job တစ်ခုစီအတွက် ရေတွက်သည်။ ပေးချေသော အစီအစဉ်များတွင် မိနစ်များ၊ တပြိုင်နက်တည်း jobs၊ ပိုကြီးသော cache နှင့် ပိုရှည်သော သိမ်းဆည်းချိန် ထပ်ပါဝင်သည်။

အစီအစဉ်အခမဲ့အခမဲ့Starter$5 တစ်လPro$10 တစ်လGrowth$19 တစ်လBusiness$29 တစ်လ
CI မိနစ်များလစဉ် 3,000လစဉ် 5,000လစဉ် 6,000လစဉ် 15,000လစဉ် 60,000
တစ်ပြိုင်နက်တည်း job များ2461020
Job အချိန်ကုန်ခြင်း360 မိနစ်360 မိနစ်360 မိနစ်480 မိနစ်720 မိနစ်
မှီခိုမှု ကက်ရှ်2 GB5 GB10 GB20 GB50 GB
သိမ်းထားသော artifact များ90 ရက်90 ရက်90 ရက်180 ရက်400 ရက်
သိမ်းထားသော log များ14 ရက်30 ရက်30 ရက်60 ရက်90 ရက်
  • ပထမအခပေးလအတွက် 50% လျှော့
  • အခပေးရသော Enzonic ဂိမ်းအစီအစဉ်ဖြင့် လစဉ် 25% လျှော့

ဈေးနှုန်းများသည် US ဒေါ်လာဖြင့်ဖြစ်သည်။ အခပေးရသော အစီအစဉ်များကို သင်၏ Enzonic လက်ကျန်ငွေမှ လစဉ် သက်တမ်းတိုးပေးသည်၊ သို့မဟုတ် လက်ကျန်ငွေ ကုန်သွားပါက ကတ်ဖြင့်။ အခမဲ့ အစီအစဉ်က ကတ် တောင်းဆိုခြင်း မရှိပါ။ Console တွင် သင့်လက်ရှိ အစီအစဉ်၏ ကန့်သတ်ချက်များကို အမြဲပြသသည်။

enzonic.dev တွင် ကန့်သတ်ချက်အားလုံးကို နှိုင်းယှဉ်ပါ

Cloud grant များ

တခြားသူများအတွက် တည်ဆောက်သူများအတွက် အခမဲ့ Pro သို့မဟုတ် Business အချိန်နှင့် $500 အထိ Cloud credit။

  • Pro သို့မဟုတ် Business ၃၊ ၆ သို့မဟုတ် ၁၂ လအတွက်
  • သင့် Enzonic လက်ကျန်ငွေတွင် $500 အထိ Cloud credit
  • Grant တစ်ခုသည် Deploy၊ Databases၊ CI နှင့် အစီအစဉ်၏ Rapidfile ကန့်သတ်ချက်များကို လွှမ်းခြုံသည်
  • လူတစ်ဦးက ဖတ်ပြီး ပုံမှန်အားဖြင့် ရက်အနည်းငယ်အတွင်း အဖြေပေးသည်

enzonic.dev ရှိ ဖောင်ဖြင့် လျှောက်ပါ။ အခမဲ့ Enzonic အကောင့်တစ်ခုသာ လိုအပ်ပြီး ကတ်မလိုပါ။

  • ပွင့်လင်းသော ရင်းမြစ်ကုဒ်
  • ကျောင်းသားများ
  • အမြတ်အစွန်းမရှိသော အဖွဲ့အစည်းများ
  • Startup များ
  • ဆရာ/မများ
  • Hackathon များ

မေးခွန်းများ

မလိုအပ်တတ်ပါ။ Enzonic CI သည် .enzonic/ci.yml သို့မဟုတ် ထောက်ပံ့ထားသော .github/workflows အပိုင်းကို ဖတ်သည်။ Windows သို့မဟုတ် macOS runner များနှင့် ပြန်သုံးနိုင်သော workflow များကဲ့သို့ run နိုင်ခြင်းမရှိသော step များကို တိတ်တဆိတ် ပျက်ကွက်မည့်အစား ရှင်းလင်းသော မက်ဆေ့ချ်ဖြင့် အစီရင်ခံသည်။

repository ချိတ်ဆက်ပြီး နောက် push ကို လည်ပတ်စေပါ။

အက်ပ်၊ ၎င်း၏ database သို့မဟုတ် upload များကိုလည်း host လုပ်နေပါသလား?