Git

Velrix kör din Git-server som en app: Forgejo, från Bibliotek. Git-servrar kopplar den sedan till realmen, så att folk loggar in med sina Velrix-konton, CI körs som Velrix-jobb och en push driftsätter dina appar.

Kom igång

1. Driftsätt Forgejo från Bibliotek. Den får en volym för sina kodförråd, som säkerhetskopieras med dina andra volymer. Ge den ett värdnamn under en domän du har bevisat.
2. Öppna Git-servrar och välj Anslut en Git-server. Välj appen; adressen är dess första värdnamn. Inloggning, CI-körare och webhook ställs in åt dig.
3. När den säger att den är klar loggar folk in i Forgejo med Velrix. För en organisations server går medlemmarna med i teamet members med skrivrätt till alla kodförråd, och administratörerna i teamet Owners, i takt vid varje inloggning.

Synka ställer in allt igen; Redigera tar ett nytt namn eller en ny adress och behåller reglerna.

En Forgejo du redan kör, som du satt upp för hand, kan också anslutas: ange då en åtkomsttoken från en av dess administratörer. Inloggningen förblir Forgejos egen; CI och driftsättning fungerar på samma sätt.

SSH

Klona och pusha över HTTPS fungerar via appens värdnamn. För Git över SSH sätter du en lastbalanserare med en TCP-port mot containerns port 2222 framför appen (Flytande IP-adresser och lastbalanserare). Serverns sida visar sedan SSH-adressen.

CI

Varje workflow-jobb körs som ett Velrix-jobb, isolerat för sig, och utdata når Forgejo medan det körs. runs-on väljer slag:

• standardetiketten: en container;
• velrix-vm: en egen microVM med egen kärna;
• velrix-builder: bygger images med buildah.

run-steg och utcheckning fungerar. Andra actions, if:, matriser och tjänster gör det inte: ett sådant jobb misslyckas direkt med en rad som säger varför. Ett jobb kan be om kärnor, minne, disk och tid, inom organisationens gränser för jobb.

Ett byggjobb får en registernyckel för just den körningen, som bara kan pusha till de kodförråd som commitens driftsättningsregler nämner och till deras byggcache. Alla andra jobb, och en pull request från en fork, får en nyckel som bara kan hämta. Körningen hittar dem som VELRIX_REGISTRY, VELRIX_REGISTRY_USER, VELRIX_REGISTRY_PASSWORD, VELRIX_IMAGE och VELRIX_BUILD_CACHE. Lager sparas i registret mellan körningarna, så ett bygge vars beroenden inte ändrats återanvänder dem (Register).

CI-körningar på serverns sida listar de senaste körningarna: varje steg med sin tid, imagebyggets steg med de cachade markerade, och den pushade imagens digest och storlek.

Driftsättning

En driftsättningsregel säger: en push till den här grenen i det här kodförrådet driftsätter den här imagen till den här appen. Imagenamnet kan använda {sha}, {short} eller {branch}. På appen syns samma regel som Inställningar › Källa:

• Driftsätts vid push: avstängt behålls regeln och bygget körs, men inget driftsätts.
• Vänta på CI: driftsätt när commitens imagebygge gått igenom, inte direkt vid push.

Inställningar › Bygge har sökvägen till Containerfile och variabler vid bygget, förseglade och givna till CI-bygget som $VELRIX_BUILD_ARGS.

Varje driftsättning är en revision som alla andra, utrullad utan avbrott och tillbakarullad om den misslyckas, med commiten, dess författare och CI-körningen på sin sida (Appar).

velrix.json

En app kan ha sina bygg- och driftsättningsinställningar i kodförrådet, som velrix.json (eller velrix.toml) i roten. Varje driftsättning läser filen i den commit som driftsätts, och det filen sätter gäller: de fälten står som Satt i velrix.json i appens inställningar. En commit utan filen lämnar tillbaka dem till inställningarna. Detaljer för varje revision visar dess inställningar som en sådan fil, att kopiera.

{
  "build": { "containerfile": "deploy/Containerfile", "args": ["API_BASE_URL"] },
  "deploy": {
    "command": "bun run start",
    "healthcheck": { "path": "/healthz" },
    "warmPaths": ["/", "/pricing"],
    "replicas": 2,
    "size": "g.medium",
    "restart": { "policy": "on-failure", "maxRetries": 5 }
  },
  "networking": { "hostnames": ["www.example.se"] }
}

• build.args namnger variabler vid bygget; värdena förblir förseglade under Inställningar › Bygge.
• deploy.warmPaths: sidor som frågas på varje ny kopia innan den får besökare (Appar).
• deploy.size anger en storlek ur katalogen; eller ange deploy.memoryMib och deploy.cpuCores.
• networking.hostnames tas bara när Inställningar › Källa › velrix.json får sätta värdnamn är påslaget, eftersom det ändrar trafiken.

Okända nycklar och felaktiga värden nekas med namn: commitens CI-körning misslyckas med en rad som velrix.json: unknown key deploy.replica, och inget driftsätts. Hela JSON-schemat finns i realmens Docs-fönster, att spara bredvid filen så att din redigerare också kontrollerar den.