Zwei Möglichkeiten, eine öffentliche GitHub Pages-Site aus einem privaten Hugo-Repository bereitzustellen

Halten Sie Ihre Entwürfe von der Öffentlichkeit fern, indem Sie fortlaufende Bereitstellungstools verwenden, um Ihre öffentliche GitHub Pages-Site zu veröffentlichen - aus einem separaten privaten Repository.

Tools wie Travis CI und Netlify bieten einige hübsche Funktionen, z. B. die nahtlose Bereitstellung Ihrer GitHub Pages-Site, wenn Änderungen in das Repository übertragen werden. Zusammen mit einem statischen Site-Generator wie Hugo ist es ziemlich schmerzlos, ein Blog auf dem neuesten Stand zu halten.

Ich habe Hugo jahrelang zum Erstellen meiner Website verwendet, aber bis zur letzten Woche habe ich mein Pages-Repository nie mit einem Bereitstellungsdienst verbunden. Warum? Da für die Verwendung eines Tools, mit dem meine Website vor der Bereitstellung erstellt wurde, das gesamte Rezept an einem Ort gespeichert werden musste - und wenn Sie GitHub Pages mit der kostenlosen Version von GitHub verwenden, ist dieser Ort öffentlich. Das bedeutet, dass alle meine drei Ideen am Morgen und die unordentlichen, unvollendeten (und nicht witzigen) Entwürfe öffentlich verfügbar wären - und keine kontinuierliche Bequemlichkeit würde mich davon überzeugen, dies zu tun.

Also habe ich die Dinge getrennt gehalten, mit Hugos chaotischen Dingen hinter den Kulissen in einem lokalen Git-Repository und dem generierten public/Ordner, der in mein GitHub Pages-Remote-Repository verschoben wurde. Jedes Mal, wenn ich meine Site bereitstellen wollte, musste ich mich auf meinen Laptop setzen und hugomeine Site erstellen, dann cd public/ && git add . && git commit... usw. usw. Und alles war gut, bis auf das quälende Gefühl, dass es einen besseren Weg gab, dies zu tun.

Ich habe vor einiger Zeit einen weiteren Artikel über die Verwendung von GitHub und Working Copy geschrieben, um Änderungen an meinen Repositorys auf meinem iPad vorzunehmen, wenn ich unterwegs bin. Es schien mir, dass ich alles tun konnte, außer meine Website von meinem iPad aus bereitzustellen, also machte ich mich daran, dies zu ändern.

Nach ein paar guten Ideen für drei Uhr morgens und einem später widerrufenen Zugriffstoken (oops) habe ich jetzt nicht nur eine, sondern zwei Möglichkeiten, um sie aus einem vollständig getrennten, privaten GitHub-Repository in meinem öffentlichen GitHub Pages-Repository bereitzustellen. In diesem Beitrag werde ich Sie durch das Erreichen dieses Ziels mit Travis CI oder mit Netlify and Make führen.

Es ist nichts Hackiges daran - mein öffentliches GitHub Pages-Repository sieht immer noch genauso aus wie beim lokalen Push von meinem Terminal. Erst jetzt kann ich einige großartige Bereitstellungstools nutzen, um die Site zu aktualisieren, wenn ich auf mein privates Repo pushe, egal ob ich auf meinem Laptop bin oder mit meinem iPad unterwegs bin.

In diesem Artikel wird davon ausgegangen, dass Sie über Kenntnisse in Git- und GitHub-Seiten verfügen. Wenn nicht, können Sie einige Browser-Registerkarten aus meinen Artikeln über die Verwendung von GitHub und Working Copy entfernen und zuerst eine Site mit Hugo- und GitHub-Seiten erstellen.

Machen wir das!

Bereitstellung von Private-to-Public-GitHub-Seiten mit Travis CI

Travis CI verfügt über die integrierte Funktion (♪), die nach einem erfolgreichen Build auf GitHub Pages bereitgestellt werden kann. Sie leisten gute Arbeit in den Dokumenten, um zu erklären, wie diese Funktion hinzugefügt wird, insbesondere wenn Sie Travis CI bereits verwendet haben… was ich nicht getan habe. Mach dir keine Sorgen, ich habe den Großteil der Dinge für dich herausgefunden.

  • Travis CI erhält alle Anweisungen aus einer Konfigurationsdatei im Stammverzeichnis Ihres Repositorys .travis.yml
  • Sie müssen ein GitHub-Token für den persönlichen Zugriff als sichere verschlüsselte Variable bereitstellen, die Sie mithilfe travisder Befehlszeile generieren können
  • Sobald Ihr Skript erfolgreich ausgeführt wurde, was Sie ihm gesagt haben (nicht unbedingt das, was Sie möchten , aber das ist ein ganz anderer Blog-Beitrag), stellt Travis Ihr Build-Verzeichnis in einem Repository bereit, das Sie mit der repoKonfigurationsvariablen angeben können .

Einrichten der Travis-Konfigurationsdatei

Erstellen Sie eine neue Konfigurationsdatei für Travis mit dem Dateinamen .travis.yml(beachten Sie das führende "."). Diese Skripte sind sehr anpassbar und ich hatte Mühe, ein relevantes Beispiel als Ausgangspunkt zu finden - zum Glück haben Sie dieses Problem nicht!

Hier ist meine Grundvoraussetzung .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

Dieses Skript lädt Hugo herunter und installiert es, erstellt die Site mit der Garbage Collection und minimiert Flags und stellt das public/Verzeichnis dann im angegebenen Verzeichnis bereit repo- in diesem Beispiel in Ihrem öffentlichen GitHub Pages-Repository. Hier können Sie die einzelnen deployKonfigurationsoptionen nachlesen .

Um das persönliche GitHub-Zugriffstoken als verschlüsselte Variable hinzuzufügen, müssen Sie Ihr Token nicht manuell bearbeiten .travis.yml. Die folgenden travisgem-Befehle verschlüsseln und fügen die Variable für Sie hinzu, wenn Sie sie in Ihrem Repository-Verzeichnis ausführen.

Installieren Sie zuerst travismit sudo gem install travis.

Generieren Sie dann Ihr persönliches GitHub-Zugriffstoken, kopieren Sie es (es wird nur einmal angezeigt!) Und führen Sie die folgenden Befehle in Ihrem Repository-Stammverzeichnis aus, wobei Sie die Küsse durch Ihr Token ersetzen:

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

Ihr verschlüsseltes Token wird auf magische Weise in der Datei angezeigt. Sobald Sie sich .travis.ymlfür Ihr privates Hugo-Repository entschieden haben, führt Travis CI das Skript aus und stellt Ihre Site bei erfolgreichem Build für Ihr öffentliches GitHub Pages-Repo bereit. Magie!

Travis führt jedes Mal einen Build aus, wenn Sie in Ihr privates Repository pushen. Wenn Sie dieses Verhalten nicht mit einem bestimmten Commit auslösen möchten, fügen Sie den skipBefehl Ihrer Commit-Nachricht hinzu.

Yo das ist cool, aber ich mag Netlify.

Okay gut.

Bereitstellung in einem separaten Repository mit Netlify und Make

Wir können Netlify dazu bringen, unsere Gebote mithilfe eines Makefiles auszuführen, das wir mit dem Build-Befehl von Netlify ausführen.

So Makefilesieht unser aus:

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"

Um den Git-Verlauf unseres separaten GitHub Pages-Repositorys beizubehalten, werden wir ihn zuerst klonen, unsere neue Hugo-Site darauf erstellen und ihn dann zurück in das Pages-Repository verschieben. Dieses Skript entfernt zunächst alle vorhandenen public/Ordner, die möglicherweise Dateien oder einen Git-Verlauf enthalten. Anschließend wird unser Pages-Repository geklont public/, unsere Hugo-Site erstellt (im Wesentlichen die Dateien in aktualisiert public/) und anschließend die neue Site in das Pages-Repository übernommen.

In diesem deployAbschnitt werden Sie Zeilen bemerken, die mit beginnen &&. Dies sind verkettete Befehle. Da Make für jede Zeile eine neue Sub-Shell aufruft, beginnt sie mit jeder neuen Zeile aus unserem Stammverzeichnis von vorne. Um cdzu verhindern, dass unsere Git-Befehle im Projektstammverzeichnis ausgeführt werden, verketten wir die Befehle und verwenden das Backslash-Zeichen, um lange Zeilen für die Lesbarkeit zu unterbrechen.

Durch Verketten unserer Befehle können wir unsere Git-Identität konfigurieren, alle aktualisierten Dateien hinzufügen und ein Commit für unser Pages-Repository erstellen.

Ähnlich wie bei der Verwendung von Travis CI müssen wir ein GitHub-Token für den persönlichen Zugriff übergeben, um es an unser öffentliches GitHub Pages-Repository zu senden. Nur Netlify bietet keine einfache Möglichkeit, das Token in unserem Makefile zu verschlüsseln.

Instead, we’ll use Netlify’s Build Environment Variables, which live safely in our site settings in the Netlify app. We can then call our token variable in the Makefile. We use it to push (quietly, to avoid printing the token in logs) to our Pages repository by passing it in the remote URL.

To avoid printing the token in Netlify’s logs, we suppress recipe echoing for that line with the leading @ character.

With your Makefile in the root of your private GitHub repository, you can set up Netlify to run it for you.

Setting up Netlify

Getting set up with Netlify via the web UI is straightforward. Once you sign in with GitHub, choose the private GitHub repository where your Hugo site lives. The next page Netlify takes you to lets you enter deploy settings:

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

I hope the effect of this new information is that you feel more able to update your sites, wherever you happen to be. The possibilities are endless — at home on your couch with your laptop, out cafe-hopping with your iPad, or in the middle of a first date on your phone. Endless!