Păstrați schițele la îndemâna publicului folosind instrumente de implementare continuă pentru a publica site-ul dvs. public GitHub Pages – dintr-un depozit privat separat.

Instrumente precum Travis CI și Netlify oferă câteva caracteristici destul de ingenioase, cum ar fi implementarea fără probleme a site-ului dvs. GitHub Pages atunci când modificările sunt trimise în depozitul său. Împreună cu un generator de site static precum Hugo, menținerea unui blog actualizat este destul de nedureroasă.

Am folosit Hugo pentru a-mi construi site-ul de ani de zile, dar până săptămâna trecută nu am conectat niciodată depozitul meu de pagini la niciun serviciu de implementare. De ce? Deoarece folosirea unui instrument care mi-a construit site-ul înainte de implementare părea să necesite întreaga rețetă într-un singur loc – și dacă utilizați GitHub Pages cu versiunea gratuită a GitHub, acel loc este public. Asta înseamnă că toate ideile mele strălucitoare de trei dimineața și proiectele dezordonate neterminate (și neobișnuite) vor fi disponibile publicului – și nicio comoditate continuă nu mă va convinge să fac asta.

Așa că am păstrat lucrurile separate, cu lucrurile murdare din spatele scenei ale lui Hugo într-un depozit Git local și public/ folderul apăsând pe depozitul meu GitHub Pages de la distanță. De fiecare dată când îmi doream să îmi implementez site-ul, trebuia să ajung pe laptop și hugo să-mi construiesc site-ul, atunci cd public/ && git add . && git commit… Etc etc. Și totul a fost bine, cu excepția sentimentului copleșitor că a existat o modalitate mai bună de a face acest lucru.

Am mai scris un articol despre ceva timp în urmă folosind GitHub și Working Copy să fac modificări în depozitele mele de pe iPad ori de câte ori sunt afară. Mi s-a părut că pot face totul, cu excepția implementării site-ului meu de pe iPad, așa că mi-am propus să schimb asta.

Câteva idei strălucitoare trei dimineața și un jeton de acces revocat mai târziu (hopa), acum nu am una, ci Două modalități de implementare în depozitul meu public GitHub Pages dintr-un depozit GitHub privat complet separat. În această postare, vă voi ajuta să realizați acest lucru cu Travis CI sau folosind Netlify și Face.

Nu există nimic ciudat – depozitul meu public de pagini GitHub arată în continuare la fel ca atunci când l-am împins local de la terminalul meu. Abia acum, pot profita de câteva instrumente de implementare grozave pentru a actualiza site-ul ori de câte ori trec la repo-ul meu privat, indiferent dacă sunt pe laptopul meu sau afară și cu iPad-ul meu.

Doua modalitati de a implementa un site public GitHub Pages
#YouDidNotPushFromThere

Acest articol presupune că aveți cunoștințe practice despre paginile Git și GitHub. Dacă nu, s-ar putea să doriți să dezactivați unele file de browser din articolele mele de pe folosind GitHub și Working Copy și construirea unui site cu Hugo și GitHub Pages primul.

S-o facem!

Implementare GitHub Pages privat-public cu Travis CI

Travis CI are capacitatea încorporată (♪) de a implementați în paginile GitHub în urma unei construcții reușite. Ei fac o treabă decentă în documentele de a explica cum să adăugați această caracteristică, mai ales dacă ați folosit Travis CI înainte … ceea ce nu am făcut. Nu-ți face griji, am făcut cea mai mare parte a lucrurilor de calcul pentru tine.

  • Travis CI primește toate instrucțiunile sale dintr-un fișier de configurare din rădăcina depozitului dvs. numit .travis.yml
  • Trebuie să furnizați un Jeton de acces personal GitHub ca o variabilă criptată sigură, pe care o puteți genera folosind travis pe linia de comandă
  • Odată ce scriptul dvs. termină cu succes ceea ce i-ați spus să facă (nu neapărat ceea ce faceți dvs.) vrei face asta, dar asta este o cu totul altă postare de blog), Travis va implementa directorul de compilare într-un depozit pe care îl puteți specifica cu repo variabila de configurare.

Configurarea fișierului de configurare Travis

Creați un nou fișier de configurare pentru Travis cu numele fișierului .travis.yml (notați „.”). Aceste scripturi sunt foarte personalizabile și m-am străduit să găsesc un exemplu relevant pe care să-l folosesc ca punct de plecare – din fericire, nu aveți această problemă!

Iată elementele mele de bază .travis.yml:

git:
 depth: false

env:
 global:
 - HUGO_VERSION="0.54.0"
 matrix:
 - YOUR_ENCRYPTED_VARIABLE

install:
 - wget -q https://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

Acest script descarcă și instalează Hugo, construiește site-ul cu colectarea gunoiului și minify steaguri, apoi implementează fișierul public/ în directorul specificat repo – în acest exemplu, depozitul dvs. public de pagini GitHub. Puteți citi despre fiecare dintre deploy opțiuni de configurare Aici.

La adăugați jetonul de acces personal GitHub ca o variabilă criptată, nu este nevoie să editați manual .travis.yml. travis comenzile gem de mai jos vor cripta și adăuga variabila pentru dvs. atunci când le rulați în directorul depozitului.

Mai întâi, instalați travis cu sudo gem install travis.

Apoi generați jetonul de acces personal GitHub, copiați-l (se afișează o singură dată!) și executați comenzile de mai jos în rădăcina depozitului dvs., înlocuind simbolul cu sărutările:

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

Jetonul dvs. criptat apare magic în fișier. Odată ce te-ai angajat .travis.yml în depozitul dvs. privat Hugo, Travis CI va rula scriptul și, dacă versiunea reușește, vă va implementa site-ul în repoblica dvs. publică GitHub Pages. Magie!

Travis va rula întotdeauna o versiune de fiecare dată când treceți la depozitul dvs. privat. Dacă nu doriți să declanșați acest comportament cu un anumit commit, adaugă skip comanda către mesajul dvs. de confirmare.

E grozav, dar îmi place Netlify.

Bine în regulă.

Implementarea într-un depozit separat cu Netlify și Make

Putem determina Netlify să facă licitarea utilizând un Makefile, pe care îl vom executa cu comanda de construire Netlify.

Iată ce este al nostru Makefile se pare ca:

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 https://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 "you@youremail.com" 
 && git config user.name "Your Name" 
 && git add . 
 && git status 
 && git commit -m "Deploy via Makefile" 
 && git push -f -q https://$(GITHUB_TOKEN)@github.com/gh-username/gh-username.github.io.git master
@echo "Pushed to remote"

Pentru a păstra istoricul Git al depozitului nostru separat de pagini GitHub, îl vom clona mai întâi, vom construi noul nostru site Hugo, apoi îl vom împinge înapoi în depozitul de pagini. Acest script elimină mai întâi orice existent public/ folder care poate conține fișiere sau un istoric Git. Apoi clonează depozitul nostru de pagini în public/, construiește site-ul nostru Hugo (în esență, actualizarea fișierelor în public/), apoi se ocupă de trimiterea noului site la depozitul de pagini.

În deploy secțiunea, veți observa liniile care încep cu &&. Acestea sunt comenzi înlănțuite. De la Make invocă un sub-shell nou pentru fiecare linie, începe din nou cu fiecare nouă linie din directorul nostru rădăcină. Pentru a ne obține cd pentru a lipi și a evita rularea comenzilor noastre Git în directorul rădăcină al proiectului, înlănțuim comenzile și folosim caracterul de bară inversă pentru rupe linii lungi pentru lizibilitate.

Înlănțuind comenzile noastre, putem configurați-ne identitatea Git, adăugați toate fișierele noastre actualizate și creați un commit pentru depozitul nostru de pagini.

În mod similar cu utilizarea Travis CI, va trebui să trecem într-un Jeton de acces personal GitHub pentru a trece la depozitul nostru public de pagini GitHub – doar Netlify nu oferă o modalitate simplă de a cripta simbolul din Makefile.

În schimb, vom folosi Netlify’s Construiți variabile de mediu, care trăiesc în siguranță în setările site-ului nostru din aplicația Netlify. Putem apoi să apelăm variabila noastră token din Makefile. Îl folosim pentru a împinge (în liniște, pentru a evita tipărirea jetonului în jurnale) în depozitul nostru de pagini prin trecându-l în adresa URL la distanță.

Pentru a evita tipărirea jetonului în jurnalele Netlify, suprimăm reteta ecou pentru acea linie cu liderul @ caracter.

Cu Makefile dvs. în rădăcina depozitului dvs. privat GitHub, puteți configura Netlify pentru a-l rula.

Configurarea Netlify

Configurarea cu Netlify prin intermediul UI web este direct. După ce vă conectați cu GitHub, alegeți depozitul privat GitHub în care locuiește site-ul dvs. Hugo. Pagina următoare pe care Netlify vă duce vă permite să introduceți setările de implementare:

Doua modalitati de a implementa un site public GitHub Pages
Creați o nouă pagină de site pe Netlify

Puteți specifica comanda de construire care va rula Makefile (make all pentru acest exemplu). Ramura de implementat și directorul de publicare nu contează prea mult în cazul nostru specific, deoarece suntem preocupați doar de a trece la un depozit separat. Puteți introduce tipicul master desfășurați sucursala și public publicați directorul.

Sub „Setări avansate de construire”, faceți clic pe „Variabilă nouă” pentru a adăuga jetonul de acces personal GitHub ca variabilă de mediu de construire. În exemplul nostru, numele variabilei este GITHUB_TOKEN. Faceți clic pe „Deploy site” pentru a face magia să se întâmple.

Dacă v-ați configurat deja depozitul cu Netlify, găsiți setările pentru implementare continuă în Setări> Construiți și implementați.

Netlify vă va construi site-ul de fiecare dată când treceți la depozitul privat. Dacă nu doriți ca un anumit commit să declanșeze o compilare, adăuga [skip ci] în mesajul dvs. Git commit.

La fel, dar diferit

Un efect al utilizării Netlify în acest fel este că site-ul dvs. va fi construit în două locuri: unul este depozitul GitHub Pages separat, public pe care Makefile îl împinge, iar celălalt este site-ul dvs. Netlify care se implementează pe CDN-ul lor de la GitHub privat conectat repertoriu. Acesta din urmă este util dacă vrei să te joci Implementați previzualizări și alte caracteristici Netlify, dar acestea nu intră în sfera acestei postări.

Principalul punct este că site-ul dvs. GitHub Pages este acum actualizat în repo-ul dvs. public. Ura!

Mergeți și desfășurați fără teamă

Sper că efectul acestor noi informații este că vă simțiți mai capabili să vă actualizați site-urile, oriunde s-ar afla. Posibilitățile sunt nelimitate – acasă pe canapea cu laptopul, în cafenea cu iPad-ul sau în mijlocul unei prime întâlniri pe telefon. Fără sfârşit!

1611993490 99 Doua modalitati de a implementa un site public GitHub Pages
Nu faceți lucruri pe telefon când sunteți la o întâlnire. Nu, oricum, dacă vrei un al doilea.