Show HN: Publish blog post with a simple Git push | Hacker News Reader

Show HN: Publish blog post with a simple Git push

github.com

96 pointssnehesht63 comments

Always like seeing these types of projects.

One piece of feedback: that gif of the process needs to be recreated. It's far too quick and the erroneous key strokes and typing/deleting is really confusing. Recreate the gif, but make it slower and error free to clearly demonstrate the process.

thanks, It's rather long ( ~ 1:30 mins ) so I increased speed by 2.5x.

Most browsers support embedded videos now, which have the advantage that you can rewind and pause. You could also provide a transcript or static screenshots.

The unfortunate thing is that GitHub flavoured markdown doesn't yet support webm or other types of video embed.

If you use github pages you can use the HTML5 video tag, here's an example from my account's Github pages

https://icpmacdo.github.io/

https://github.com/icpmacdo/icpmacdo.github.io

Github pages renders html so by default it supports video, However It's totally different case with markdown files.

Though it's not embeddable, tools like asciinema [0] are great for this, too.

[0] https://asciinema.org/

Now it is too slow and I got bored waiting ;-)

Use the fast-forward button, that is available on any decent video viewer. Oh wait.

Dont want to be a bubble-burster here.This can also be achieved by picking any of the blog engines[1] and hooking it up with a CI. Gives you much more legroom then right?

[1]:https://www.staticgen.com/

There's this guide on a "one cent blog"[0] that I've used to create my own website / weblog with a custom domain. It uses Jekyll, CloudFlare and Travis-CI. Probably a bit more work to set up then the tool created by the OP, but also more flexible, I would think. The end result is much the same though. A simple 'git push' is used to publish the blog.

---

[0]: https://hugotunius.se/2016/01/10/the-one-cent-blog.html

I'm the author of "One Cent Blog" thanks for the mention glad it helped you. One interesting difference between the approach described in my blog post(or any other static method) is that you are not relying on a server or a database that can fall over if you get a lot of traffic from say HN. Having static files is a blessing because it scales wonderfully.

The approach in this post relies on maintaining infrastructure, keeping it up to date and patched which for me is a lot of extra work I'd rather not do. Using a standard VPS it's a lot more expensive too.

I do this with jekyll and github but without s3 or travis-ci. I skimmed over the blog but couldn't understand what value s3 adds vs letting github host it. Cloudflare can do the https bits with github directly.

The main value is escaping the constraints on plugins and gems you are able to use with Jekyll on GitHub pages. Don't remember of the top of my head but I believe it's pretty limited.

Reminds me of my old project (still in use to this days by something like a dozen people) fugitive [1].

[1] http://shebang.ws/fugitive-readme.html

I considered doing this with my hugo blog, but decided I wanted to do the work on my client and keep my server stupid. In order to build my site, I have a lot of minification, pdf generation, syntax highlighting etc, that requires a few packages to be installed on the client.

If my server had to rebuild after a git push of a new post, I'd have to install all of the tooling on the server. I just commit my post, then run npm deploy which rsyncs all the static assets to the server after building on the client. This also makes it so I can see everything on my client easily before deploying. If I was building a blog for someone else though, this would make sense, stupid client, smart server, commit from anywhere.

My motivation for this project was simple, I need a good interface to write my articles from different devices and able to publish them without touching the server.

I built this in such a way I don't need to think about database backups, server side authentication, using dropbox to sync my unfinished articles.

This architecture offers me freedom to write on my phone (Termux) during commute or sitting in the office and keep track of changes using git and finally publishing the post by simply adding a record into metadata.json.

You could throw Jekyll, Middleman, Pelican or Hugo on the server and run their build command with a git hook. Then you'd get the same result, but a completely static website without the server needing flask to piece together pages when a user hits the site.

The build times wouldn't be instantaneous as it would need to regenerate all the pages, but Hugo is still really snappy for even a large site. You probably post less than users access anyway.

This would still check all your boxes:

No database

No server side auth

Non-public drafts (metadata)

Commit from anywhere

Bonus: Dumb serving (only prebuilt static pages)

Optional bonus: Shortcodes, themes, bells whistles

The site would be built on the server so it wouldn't be completely dumb like rsync-ing static pages to nginx or something, but that's the rub if you want to be able to use clients with only git as a dependency.

Yours is a good solution, I'm just throwing an idea out there for a pre-baked alternative. My original use case didn't call for mobile blogging (not a fan), I run my own gitolite server so auth is already in my camp and I have a multi-tooled build that I didn't want on the server. If something breaks, it happens on my machine instead of on my server.

Also just a tip, maybe you want to put a <noscript> tag around an expanded copy of your hamburger menu. Without javascript, your website navigation is broken because you can't expand the menu.

Edit: by client, I mean blog-editing-computer not blog-reader's-computer.

What you said is true but where's the fun in it. I started this project as a simple django blog, included react little later and then scratched the whole thing and finally built this. It was fun working on this.

About the menu, I was planning to update it to hamburger icon with animations. For now the icon doesn't change and the menu is injected into adjacent/bottom element based on screen size.

Thanks your feedback though.

What you describe is pretty similar setup to my blog. Im using Jeykll with Bitbucket Pipelines, when I push it builds the site and uploads it to S3.

Interesting to hear your experiences. I'm doing something similar, with a large number of files in the static directory which never change. Hugo seems to lack any knowledge about which files it changed, so it's a huge re-upload every time (I'm using AWS S3 sync).

It would be nice if Hugo could remember if it touched a file or not. AFAICT it just copies everything over each time and changes the datestamp. Even with rsync this is a lot of useless work.

I've got a script which does a git pull every 5 minutes, with automatic hugo build. It works (Hugo doesn't crash that often) and is simple enough for me.

How is this different to hosting a Jekyll site on github?

Jekyll on Github does not allow plugins. Though I'd say that this seems to be a bit an overkill, one shouldn't need cntainers for this kinda task. Best approach would be local build+rsync/ssh for a normal hosting. For github, I'd build the site targeting another git repo that I'd push to github.

I've been publishing stuff on the web for years using just a simple scp.

And if you need versioning, just create a git repository on the remote server.

    rsync -a ~/blog/ user@host:~/blog && \
    ssh user@host 'cd ~/blog && git add --all . && git commit -m "udpate"'

Shouldn't one not version-control the build-output?

Or rsync...

scp is useful as always.

Seems to me that publishing blog post through git push is much more work than use some admin interface (for example Wordpress).

You can use it from any device (without aby app for CLI interface). You can use for example VersionPress[1] for backups to git. And I don't get what's the point of publishing without touching server, since you need to touch the server to view published post.

[1] https://versionpress.net/

Different strokes.

I think maintaining the LAMP Wordpress stack, extensions, admin panel auth security, whatever versionpress is etc. is more hassle than editing a text file and pushing code. To devs, this editing is second nature.

Also, I'd take my desktop editor to a contentEditable any day.

Github has a nice web interface for directly editing files and creating Git commits from them (and Pull Requests), which is why I like to stick to the GH Pages flavor of Jekyll. It's nice having the option for a web interface for quick edits and the editor of my choice for long form posts. The Github website is the only reason I use Jekyll over many of the more recent alternatives like Middleman/Hugo/et al.

I used wordpress for a couple of years, It's good for a general purpose blog, but as codesim365 said I like CLI than web interface and it's too much hassle maintaining WordPress( Regular updates and security patches, database backups and sync to dropbox or s3 )

With a CMS for static websites like DatoCMS [1] you can have the best from both words: edit your post from a good old web interface and publish a rock solid, stupid, static website.

[1]: https://www.datocms.com

What about commit names? Here's what happens when you use git for commiting changes that do not support a meaningful name: https://github.com/github/developer.github.com/commits/gh-pa...

How is this different from Jekyl?

Looks like this doesn't generate a static site, but instead dynamically reads the content out of the blog "post" files and renders it on request.

I haven't used jekyll much but I would say this stores posts in separate git repo (github.com/snehesht/blogposts) and user doesn't need to update the server every time he publishes a new post.

It uses github webhooks to alert server of any events related to the blogposts repo. The server verifies the events using HMAC authnication ( see github docs for more info) and then updates the local blogposts repo ( git pull)

With github pages and Jekyll, updating the blog is also just a simple push of the Jekyll sources. The HTML page generation will than happen on github's side. Of course with this, you're locked down to 2 techs, github and Jekyll.

Being locked into Jekyll is not such a huge deal, as the posts are all Markdown with some YAML frontmatter, and other systems use the same post conventions, such as Middleman. Github only provides the convenience of not having to install Jekyll on your own system in order to publish. If you want to throw it up to S3 or any other static file server, you just have to run `jekyll build` yourself.

Not really locked in to Github, it's easy to replace it with any git server using a post-receive hook.

Yeah Gitlab provides this type of functionality out of the box. Whenever I commit something to it I get updates on my website[0] immediately.

Same for my CV[1], whenever I change it in gitlab it picks it up, compiles the latex to pdf and replaces the cv.pdf file.

[0] https://gitlab.com/stanislavromanov/stanislavromanov

[1] https://gitlab.com/stanislavromanov/cv

So does GitHub

https://help.github.com/articles/about-github-pages-and-jeky...

Both my current[1] and previous[2] blog engines work like this - as long as the post tree is updated by git or Dropbox, they're perfectly happy. Plus I can use whatever markup I want (even Jupyter notebooks).

1: https://github.com/rcarmo/sushy 2: https://github.com/rcarmo/yaki

Alternatively you can setup a pipeline on gitlab and let the runner build/publish your blog

That's an interesting idea, but I wanted this blog to be as simple as possible.

Shameless Plug: https://zammu.in/ is something which I built. It is a CI for static site generators like Jekyll/Hugo/Middleman etc,.

Why would I want to use Zammu over just using Travis CI or any other existing CI service? The only new feature I see is scheduled deploys. (It's not clear to me from the description on the site how this work.) Unfortunately it doesn't seem the SSG I currently use (Wintersmith) is supported anyway. Although I don't see why adding specific support for each system should be necessary.

Damn, this is cool. I have been meaning to build something similar, inspired by Gollum, or Jekyl.

Thanks a lot, feel free to use my code as you see fit.

I probably will :)

I use a similar workflow. Emacs Org mode --> HTML --> Git Push --> Auto Publish

It would be cool to implement this as githook -> AWS Lambda -> publish to s3 bucket.

Lambda is cool to some extent, actually I'm working on a side project that relies heavily on aws lambda.

"simple" and Git don't go together.

It's not user hostile, it's just only expert-friendly.

Git add/commit/push/pull is all you need to know for a typical blog. Doesn't get much simpler than that.

"Simple" and Magit, however, go together like peanut butter and jelly.

Great project. Cheers!

I see that you use keybase.io, can you send me an invite if that's okay for you?

Thanks, I got mine from a friend, I'll check if he have any invites left.

Are you still looking for an invite?

I got one yesterday. Most probably a Hacker News reader gave me one :)

`git push` is in no way simple.

Why not? are you saying the CLI isn't simple or git in particular?

Reply on news.ycombinator.com