Closed jarib closed 9 years ago
Hmm, hva om vi kan bruker samme "engine" til å lage statiske sider som ikke lenkes opp på bloggen men som finnes. Slik at en kan se de i kontekst av bloggen men at den ikke blir publisert.
Ja, det er en mulighet å lage vår egen versjon av _drafts
som ligger ute men er skjult med mindre man har direktelenken.
Alternativet blir vel å hoste et slags testmiljø selv. Men det er fort en del jobb, spesielt hvis det skal integreres med brancher/webhooks osv. På den annen side har vi laget litt kode for dette fra før som kanskje kan gjenbrukes på en eller annen måte.
En mer hackete løsning er å kjøre opp jekyll serve -w --drafts
på en server og en cron-jobb som puller fra git med jevne mellomrom.
Ja, det er ikke helt rett frem hvordan en kan gjøre dette på en god måte. Det beste hadde vel vært å hoste ut det som er i draft mappa på en måte. Hva med å forke hdo-blog til hdo-draft og synce alle commits over dit bare at på den siden så hostest det som er i draftsmappa.
Mm, også en mulighet. Men føles litt uelegant med to identiske repoer bare for å få GitHubs hosting.
Kanskje det er mulig å sørge for at det som ligger i drafts hostes ut på samme blog men at det ikke havner i feeden, på forsiden eller i arkivet. På den måten så er det bare de som kjenner urlen som kan se posten. Vi kan jo lage et flag i YAML fila som heter published: true/false så trenger vi ikke bruke drafts engang
Jekyll har allerede støtte for å sette published: true|false
på vanlige _posts
, men de som er false
vil da ikke havne i den genererte siten (i _site
). Men ja, vi kunne laget vår egen versjon av det.
Vi trenger jo egentlig at den havner i _site men at den ikke tas med som en post alle andre steder.
Jepp. Vi kunne hatt et flagg i YAML, ulempen er at vi da må huske å filtrere alle steder hvor vi bruker site.posts
. Vi får gruble litt på det, takk for innspill.
Det er ikke ideelt men vi ønsker vel at det kommer så nært bloggen så mulig.
Jeg tror jeg går for å hoste en egen versjon som bygges via hdo-webhook-deployer. Det åpner også opp for at vi kan hoste bloggen selv i fremtiden, som kan være nyttig om vi vil bruke plugins som ikke er støttet på Github Pages.
Bloggen serves nå med --drafts
fra stagingserveren på http://drafts.holderdeord.no/. Har ikke satt opp noen auto-oppdatering via hdo-webhook-deployer enda, det får bli en fremtidig forbedning.
Så repoet hdo-blog blir kjørt opp på drafts.holderdeord.no med --drafts. Er det enkelt å laste opp nytt innhold manuelt eller må man ha tilgang til serverene ol.
Man må ha tilgang til serveren nå, men planen er å få autooppdatring via Travis webhook.
Ja, da går det jo av seg selv. Lurt. Jeg liker løsningen =)
:+1:
@jarib Jeg prøvde å se på deployeren men fikk ikke helt til å fungere. Mulig jeg er utålmodig og at den kommer ut snart men for meg virket det ikke som det var sånn rett frem og se status.
Utifra lenken du postet som ser slik ut http://deploy.holderdeord.no/output/holderdeord/hdo-blog/gh-pages/2014-12-08/005705/3759141bb4693ae8e277925a9b7fd28a4a349de0.log Ser det ut som det er repo, dato, et tall 005705 muligens bygg nummer så commiten 3759141bb4693ae8e277925a9b7fd28a4a349de0 Er dette repoet til den deployeren https://github.com/holderdeord/hdo-webhook-deployer ?
Edit: Jeg la til Alexander sin post og ville bare få den ut på drafts =) https://github.com/holderdeord/hdo-blog/commit/dc114c300a608e3da13e2d49fae294958934ce89
Ja, det er repoet. Deployment trigges når dette bygget er ferdig, og dukker da opp i lista på http://deploy.holderdeord.no/.
Ah, sweet! Utålmodige meg. Ser ut som Travis bygget står i kø.
Artiklene våre vil kanskje skrives i Google Docs/Word i en tidlig fase, men forhåpentligvis utvikle seg til å være samarbeidsprosjekter mellom skribenter, designere og utviklere. I dag er man nødt til å kjøre Jekyll lokalt for å lese artikler som er under utvikling.
Hvordan kan vi best dele artikler som er under arbeid i en senere fase, hvor ikke bare tekst, men også design/visualisering/kode også skal vises fram?
Ideer mottas med takk!