To måder at implementere et offentligt GitHub Pages-sted fra et privat Hugo-arkiv

Hold dine kladder ude af offentligheden ved at bruge kontinuerlige implementeringsværktøjer til at udgive dit offentlige GitHub Pages-websted - fra et separat privat arkiv.

Værktøjer som Travis CI og Netlify tilbyder nogle smukke smarte funktioner, som problemfri implementering af dit GitHub Pages-websted, når ændringer skubbes til dets lager. Sammen med en statisk stedgenerator som Hugo er det ret smertefrit at holde en blog opdateret.

Jeg har brugt Hugo til at opbygge mit websted i årevis, men indtil denne sidste uge havde jeg aldrig tilsluttet mit Pages-arkiv til nogen implementeringstjeneste. Hvorfor? Fordi det brugte et værktøj, der byggede mit websted, inden jeg implementerede det, krævede at have hele opskriften ét sted - og hvis du bruger GitHub Pages med den gratis version af GitHub, er dette sted offentligt. Det betyder, at alle mine lyse ideer om morgenen tre-om-morgenen og rodet ufærdige (og uheldige) kladder ville være offentligt tilgængelige - og ingen mængde kontinuerlig bekvemmelighed ville overbevise mig om at gøre det.

Så jeg holdt tingene adskilt med Hugos rodede bag kulisserne i et lokalt Git-arkiv og den genererede public/mappe, der skubbede til mit GitHub Pages-fjernlager. Hver gang jeg ønskede at distribuere mit websted, skulle jeg gå på min bærbare computer og hugobygge mit websted, så cd public/ && git add . && git commit... osv. Osv. Og alt var godt bortset fra den nagende følelse af at der var en bedre måde at gøre dette på.

Jeg skrev en anden artikel et stykke tid tilbage om brug af GitHub og Working Copy til at foretage ændringer i mine arkiver på min iPad, når jeg er ude og omkring. Det syntes for mig, at jeg kunne gøre alt undtagen at distribuere mit websted fra min iPad, så jeg satte mig for at ændre det.

Et par lyse ideer tre om morgenen og et tilbagekaldt adgangstoken senere (oops), jeg har nu ikke en, men to måder at distribuere til mit offentlige GitHub Pages-arkiv fra et helt adskilt, privat GitHub-lager. I dette indlæg tager jeg dig gennem at opnå dette med Travis CI eller ved hjælp af Netlify og Make.

Der er ikke noget hackish ved det - mit offentlige GitHub Pages-lager ser stadig ud som det gjorde, da jeg skubbede til det lokalt fra min terminal. Først nu er jeg i stand til at drage fordel af et par fantastiske implementeringsværktøjer til at få webstedets opdatering, når jeg skubber til min private repo, uanset om jeg er på min bærbare computer eller ud og rundt med min iPad.

Denne artikel antager, at du har arbejdskendskab til Git- og GitHub-sider. Hvis ikke, vil du muligvis afvise nogle browserfaner fra mine artikler om brug af GitHub og Working Copy og opbygning af et websted med Hugo og GitHub Pages først.

Lad os gøre det!

Privat-til-offentlig implementering af GitHub-sider med Travis CI

Travis CI har den indbyggede evne (♪) til at implementere til GitHub Pages efter en vellykket build. De gør et anstændigt stykke arbejde i dokumenterne med at forklare, hvordan du tilføjer denne funktion, især hvis du har brugt Travis CI før ... som jeg ikke har gjort. Bare rolig, jeg lavede størstedelen af ​​at finde ud af tingene for dig.

  • Travis CI får alle sine instruktioner fra en konfigurationsfil i roden til dit arkiv kaldet .travis.yml
  • Du skal give et personligt GitHub-adgangstoken som en sikker krypteret variabel, som du kan generere ved hjælp travisaf kommandolinjen
  • Når dit script er færdigt med at gøre det, du har bedt det om at gøre (ikke nødvendigvis hvad du vil have det til at gøre, men det er et helt andet blogindlæg), vil Travis distribuere dit build-bibliotek til et lager, du kan specificere med repokonfigurationsvariablen.

Opsætning af Travis-konfigurationsfilen

Opret en ny konfigurationsfil til Travis med filnavnet .travis.yml(bemærk det førende “.”). Disse scripts er meget tilpasselige, og jeg kæmpede for at finde et relevant eksempel til brug som udgangspunkt - heldigvis har du ikke det problem!

Her er min grundlæggende .travis.yml:

git: depth: false env: global: - HUGO_VERSION="0.54.0" matrix: - YOUR_ENCRYPTED_VARIABLE install: - wget -q //github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_Linux-64bit.tar.gz - tar xf hugo_${HUGO_VERSION}_Linux-64bit.tar.gz - mv hugo ~/bin/ script: - hugo --gc --minify deploy: provider: pages skip-cleanup: true github-token: $GITHUB_TOKEN keep-history: true local-dir: public repo: gh-username/gh-username.github.io target-branch: master verbose: true on: branch: master

Dette script downloader og installerer Hugo, bygger webstedet med affaldssamlingen og minimerer flag og distribuerer derefter public/biblioteket til det angivne repo- i dette eksempel er dit offentlige GitHub Pages-arkiv. Du kan læse om hver af deploykonfigurationsindstillingerne her.

For at tilføje GitHub-adgangstokenet som en krypteret variabel behøver du ikke manuelt redigere din .travis.yml. De travisperle kommandoer nedenfor vil kryptere og tilføje variablen for dig, når du kører dem i dit arkiv mappe.

Først skal du installere travismed sudo gem install travis.

Derefter genererer dit GitHub-personlige adgangstoken, kopierer det (det vises kun en gang!) Og kør kommandoerne nedenfor i din depotrod, og udskift kysene med dit token:

travis login --pro --github-token xxxxxxxxxxxxxxxxxxxxxxxxxxx travis encrypt GITHUB_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxx --add env.matrix

Dit krypterede token vises magisk i filen. Når du først har forpligtet dig .travis.ymltil dit private Hugo-arkiv, kører Travis CI scriptet, og hvis bygningen lykkes, distribueres dit websted til din offentlige GitHub Pages-repo. Magi!

Travis kører altid en build hver gang du skubber til dit private lager. Hvis du ikke vil udløse denne adfærd med en bestemt forpligtelse, skal du tilføje skipkommandoen til din forpligtelsesmeddelelse.

Yo det er sejt, men jeg kan godt lide Netlify.

Okay fint.

Implementering til et separat lager med Netlify og Make

Vi kan få Netlify til at udføre vores bud ved hjælp af en Makefile, som vi kører med Netlify's build-kommando.

Sådan Makefileser vores ud:

SHELL:=/bin/bash BASEDIR=$(CURDIR) OUTPUTDIR=public .PHONY: all all: clean get_repository build deploy .PHONY: clean clean: @echo "Removing public directory" rm -rf $(BASEDIR)/$(OUTPUTDIR) .PHONY: get_repository get_repository: @echo "Getting public repository" git clone //github.com/gh-username/gh-username.github.io.git public .PHONY: build build: @echo "Generating site" hugo --gc --minify .PHONY: deploy deploy: @echo "Preparing commit" @cd $(OUTPUTDIR) \ && git config user.email "[email protected]" \ && git config user.name "Your Name" \ && git add . \ && git status \ && git commit -m "Deploy via Makefile" \ && git push -f -q //$(GITHUB_TOKEN)@github.com/gh-username/gh-username.github.io.git master @echo "Pushed to remote"

For at bevare Git-historien for vores separate GitHub Pages-arkiv kloner vi først det, bygger vores nye Hugo-sted til det og skubber det derefter tilbage til Pages-arkivet. Dette script fjerner først enhver eksisterende public/mappe, der muligvis indeholder filer eller en Git-historie. Det kloner derefter vores Pages-arkiv til public/, bygger vores Hugo-websted (opdaterer i det væsentlige filerne public/) og sørger derefter for at forpligte det nye websted til Pages-arkivet.

I deploysektionen bemærker du linjer, der starter med &&. Disse er kædede kommandoer. Da Make påberåber sig en ny sub-shell for hver linje, starter den forfra med hver nye linje fra vores rodkatalog. For at få os cdtil at holde fast og undgå at køre vores Git-kommandoer i projektets rodmappe, kæder vi kommandoerne og bruger tilbageslagstegnet til at bryde lange linjer for læsbarhed.

Ved at sammenkæde vores kommandoer er vi i stand til at konfigurere vores Git-identitet, tilføje alle vores opdaterede filer og oprette en forpligtelse til vores Pages-arkiv.

På samme måde som ved brug af Travis CI skal vi sende et personligt GitHub-adgangstoken for at skubbe til vores offentlige GitHub Pages-lager - kun Netlify giver ikke en ligetil måde at kryptere tokenet i vores Makefile.

I stedet bruger vi Netlify's Build Environment Variables, som lever sikkert i vores webstedsindstillinger i Netlify-appen. Vi kan derefter kalde vores tokenvariabel i Makefile. Vi bruger det til at skubbe (stille for at undgå at udskrive token i logfiler) til vores Pages-arkiv ved at sende det i den eksterne URL.

For at undgå at udskrive tokenet i Netlifys logfiler, undertrykker vi opskriften, der ekko for den linje med det ledende @tegn.

Med din Makefile i roden af ​​dit private GitHub-arkiv kan du konfigurere Netlify til at køre det for dig.

Opsætning af Netlify

At komme i gang med Netlify via web-UI er ligetil. Når du har logget ind med GitHub, skal du vælge det private GitHub-lager, hvor dit Hugo-sted bor. Den næste side Netlify tager dig til, giver dig mulighed for at indtaste implementeringsindstillinger:

You can specify the build command that will run your Makefile (make all for this example). The branch to deploy and the publish directory don’t matter too much in our specific case, since we’re only concerned with pushing to a separate repository. You can enter the typical master deploy branch and public publish directory.

Under “Advanced build settings” click “New variable” to add your GitHub personal access token as a Build Environment Variable. In our example, the variable name is GITHUB_TOKEN. Click “Deploy site” to make the magic happen.

If you’ve already previously set up your repository with Netlify, find the settings for Continuous Deployment under Settings > Build & deploy.

Netlify will build your site each time you push to the private repository. If you don’t want a particular commit to trigger a build, add [skip ci] in your Git commit message.

Same same but different

One effect of using Netlify this way is that your site will be built in two places: one is the separate, public GitHub Pages repository that the Makefile pushes to, and the other is your Netlify site that deploys on their CDN from your linked private GitHub repository. The latter is useful if you’re going to play with Deploy Previews and other Netlify features, but those are outside the scope of this post.

The main point is that your GitHub Pages site is now updated in your public repo. Yay!

Go forth and deploy fearlessly

Jeg håber, effekten af ​​disse nye oplysninger er, at du føler dig bedre i stand til at opdatere dine sider, uanset hvor du tilfældigvis er. Mulighederne er uendelige - derhjemme på din sofa med din bærbare computer, café-hopping med din iPad eller midt i en første date på din telefon. Endeløs!