Forbind GitHub og deploy ved hvert push
Installer Suble Deploy GitHub-appen, og dine repos og branches dukker op i dashboardet — ingen URL'er eller tokens at indsætte. Peg en cluster-service mod et repo, og hvert git push bygger et nyt image og ruller det ud. Private repos klones med kortlivede installations-tokens, og appen beder kun om læseadgang.
The Suble team
Engineering ·
At forbinde et repository til Suble betød før, at man skulle indsætte en personlig access-token. Nu er der en renere vej: installer Suble Deploy GitHub-appen en gang, vælg et repo og en branch, og hvert push bliver til en kørende release. Det er den GitHub-native front-end til de cluster-git-builds, du allerede kender — samme on-demand builder, samme rullende deploy, uden copy-paste.
Forbind med et klik
Det bor i dashboardet, under Projekt → Indstillinger → Git. Tryk Forbind GitHub, og installer appen på din organisation eller konto — ingen URL'er, ingen tokens. Når du kommer tilbage, ligger dine repositories og branches allerede klar i dropdowns.
- Installer appen. Fra Projekt → Indstillinger → Git klikker du Forbind GitHub og vælger den organisation eller konto, Suble Deploy skal installeres på.
- Tilføj en service fra et repo. I et cluster vælger du Tilføj service → GitHub-app, og vælger så installationen, repositoryet og den branch der skal følges.
- Vælg hvordan det bygger. Dockerfile, Railpack eller Static, plus en base-mappe — og lad Auto-deploy ved push være tændt (det er tændt som standard).
Projekt → Indstillinger → Git
[ Forbind GitHub ] → installer Suble Deploy
✓ 1 installation · 24 repositories tilgængelige
Cluster → Tilføj service → GitHub-app
Installation acme
Repository acme/web
Branch main
Build-metode Dockerfile
Auto-deploy ved push ✓Private repos, ingen tokens at indsætte
Private repositories virker i det øjeblik, appen er installeret. Der er ingen token at gemme: hver build kloner med en kortlivet installations-access-token, som Suble laver netop til det build. Den gemmes aldrig, og den skrives aldrig ind i imaget — så en kørende container kan ikke læse dine credentials.
Tokens laves pr. build
Klon-credentialen laves når et build starter og udløber straks efter. Intet langlivet ligger på disk, og intet ender i imaget. (Den ældre metode med at indsætte en personlig access-token virker stadig, hvis du foretrækker den.)
Hvert push sendes ud
Når en service er forbundet, fyrer et git push til den fulgte branch et webhook af. Suble bygger imaget igen på on-demand builderen, og dit cluster ruller det ud med en rullende deploy — en replica ad gangen, mens build-loggen streamer til dashboardet hele vejen. Ingen CI at koble op, ingen build-boks der skal køre.
Vil du ikke have en branch til at sende ud automatisk? Auto-deploy ved push er en indstilling pr. service — slå den fra og byg i hånden, når du er klar. Slå den til igen, og du pusher for at deploye igen.
Mindst mulige rettigheder som standard
Appen beder om så lidt som muligt. Den anmoder kun om læseadgang til repositoryets Contents og Metadata — nok til at klone og holde øje med pushes, intet mere. Og den der forbinder skal faktisk eje installationen: det bekræftes via GitHub OAuth ved forbindelsestidspunktet, så du kan ikke koble et repo op, du ikke styrer.
Læseadgang, kortlivet, ejer-bekræftet
Contents + Metadata, kun læsning. Ejerskab tjekket via GitHub OAuth. Klon-tokens laves pr. build og smides væk bagefter. Det er hele sikkerhedsfladen.
Prøv det
Åbn Projekt → Indstillinger → Git, forbind GitHub, og peg en cluster-service mod et repo — det næste push sender sig selv ud. Den totrins-gennemgang findes i Forbind GitHub, og den fulde build-reference (metoder, base-mappe, on-demand builderen) bor i Cluster Git-builds.
Skrevet af
The Suble team
Engineering