If you have read my post about my blog framework consideration, then you may know that I chose:
- Hugo: for my blog framework, one of popular Static Site Generator frameworks out there.
- Gitlab Page: for hosting my static content.
- Gitlab CI: for automate my blog deployment to Gitlab Page.
My quote from that post:
Choosing Hugo as my blog content engine comes to 1 consequence: only Gitlab Page support Hugo with Gitlab CI to automate the process of publishing the website. On the other hand, GitHub Page only supports Jekkyl.
Actually I can use both, but I have to spend more effort on the CICD thing when using GitHub and no seamless experience on that yet. Gitlab basically offer the simplicity by providing Hugo Blog Template and Hugo CICD template, that’s a win for me 💛 (at least in the beginning)
Yup, I have to say using Gitlab Page and Gitlab CI is really simple and very straightforward for a beginner like me. It helped me to focus on learning Hugo system for a while at beginning, at least for the first 2 hours since I had started to bootstrap my blog then.
In that first 2 hours, I also tried figuring out how my ideal blog writing and blog tuning workflow could be. Note that this workflow is thought by assuming that the blog author is only myself.
This was what I had thought due to my blog system setup at that moment: for each 1 single task (such as: add new content, fixing comment integration section, etc):
- Create a new branch from
- Make a change
hugo servein local to check how it looks
- Fix it and try again, go to point 3 until satisfied, then
- Merge it with master
- Push it to origin Gitlab, then Gitlab CI will take care of it
But then I realized the existing workflow using that system, has some downsides:
Can’t live preview online on a certain branch. This is a major downside for me. The gaps that it can be filled:
- Final test before going live to production blog. It is necessary and very practical, since testing my blog locally doesn’t catch all integration aspects. Example: Disqus comment section and social sharing feature aren’t working well in local mode. Even there are bug occurrences in my content that doesn’t get caught at local-test but somehow broken when going live. This is mostly due to me messing up with hyperlink and base URL path stuff.
- Very convenient for sharing with friends for proofreading.
The workflow above makes me rely on my laptop to do blogging. This is actually not a major complaint, but nice to have solution for this.
- Very often, when I was away quite a long time (e.g: travel, stroll around), I draft my new blog post on my mobile phone. To post through via mobile phone is almost impossible. Actually you can: by using Gitlab online editor. But that’s not really good interface. Besides, uploading the image and refer it to content post is harder in mobile (believe me, I’ve tried it, it made me irritated). The workflow requires me to have access on my terminal: to use git command, hit hugo serve to check locally.
So the next 1 hour, I had been frantically trying to search for “easy and simple” solution to address those weak points and finally found it 😏
In previous post, I have explained some important setting and configuration on Hugo site so you can personalize it to your own like.
Create New Post and Page
Now comes the important part of the blog itself, the content, writing the content and publish it.
Basically there are 2 categories of content:
Page as explained in
content directory section of my previous post:
pageThis is a placeholder where you can put all independent page that doesn’t show like the post entry. For example:
Contact Us, and
postAll content in this folder will appear descendingly by post’s published date. This will be your main folder where you put the site’s posts.
Create new post and page is similar.
To create a new post, put it under
hugo new content/post/<title>.md
And to create a new page, put it under
hugo new content/page/<title>.md
On the previous post, I have explained how to bootstrap the blog repository and its CICD and publish it to the public. The site is accessible from
https://<user>.gitlab.io/<repo-name>, in case of mine: https://bangau1.gitlab.io/my-blog/.
A bit of disclaimer, that is not my real blog repository. Mine is private 😄
Hugo Directory and Content Structure
Disclaimer: I only explain the content structure of Hugo, the Hugo Template by Gitlab.
Now, before we take a look at some important configuration in Hugo, let me explain in general how the Hugo content structure
├── config.toml ├── content │ ├── _index.md │ ├── page │ │ └── about.md │ └── post │ ├── 2015-01-04-first-post.md │ ├── 2015-01-15-pirates.md ├── resources │ └── _gen │ ├── assets │ └── images ├── static │ └── favicon.ico └── themes └── beautifulhugo
As explained in my previous blog post, I have to chose Gitlab Page as it offers seamless experience on setting up my preferred Static Site Generator: Hugo and the necessary CI/CD. The CI/CD is necessary here since the public site is in HTML format, but my blog content will be in a mix of Markdown, HTML, and some templating format stuff. The CI/CD is using Gitlab CI, invoking specific Hugo command to generate all my content to HTML format.
Now, about Gitlab Page itself, this is a feature offering by Gitlab, so everyone can put static content and publish it publicly accessible from:
https://<user>.gitlab.io/<repo-name>, if you chose the Project Site, or
https://<user>.gitlab.io, if you chose the User or Organisation Site
I chose the first option due to the fact I maybe in future will introduce another Gitlab Page and I don’t want to mess my another blog if I chose the second option, since it has common subdomain and prefix.