agj/blog
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: typos
All checks were successful
Release CI action / build-and-push-container (push) Successful in 3m14s
Details

Browse Source
This commit is contained in:
Asger Gitz-Johansen 2024-12-02 20:06:55 +01:00
parent f65657a781
commit 3e4bf792fe
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
content/posts/how-to-blog.md
View File

@ -64,7 +64,7 @@ For now, I am just using the built-in server in `hugo`, but it should be possibl
I mentioned `hugo` before, but I was mostly mad that I had to add the autogenerated stuff in git - with this approach... I don't have to 🎊! I mentioned `hugo` before, but I was mostly mad that I had to add the autogenerated stuff in git - with this approach... I don't have to 🎊!
## Images ## Images
Just put images in the `static` directory, and reference to them in your blogposts like you would normally in a `hugo` project: Just put images in the `static` directory, and reference to them in your blog posts like you would normally in a `hugo` project:
```markdown ```markdown
![example](/example.png) ![example](/example.png)
@ -110,7 +110,7 @@ Yes! Now we're cooking with gas! ... or atleast cooking with something. Note tha
## Conclusion ## Conclusion
We have made a docker file for automatically downloading, generating and serving a simple `hugo` blog site. We have made a docker file for automatically downloading, generating and serving a simple `hugo` blog site.
Personally, I would've liked the `static` and `shortcodes` directories to not exist, but blogposts need images and it needs to center them, so they are a necessary evil. Personally, I would've liked the `static` and `shortcodes` directories to not exist, but blog posts need images and it needs to center them, so they are a necessary evil.
Could we make the directory structure better and cleaner? Probably yes. Could we make the directory structure better and cleaner? Probably yes.
Will I make it better for this blog in the future? Probably yes. Will I make it better for this blog in the future? Probably yes.
Will I make another post when I do that? Probably yes! Will I make another post when I do that? Probably yes!
@ -120,7 +120,7 @@ The next section concerns about hosting, orchestrating and deploying the site au
# Deployment # Deployment
Being able to build and launch the docker image is nice and can suffice for smaller projects. Being able to build and launch the docker image is nice and can suffice for smaller projects.
Yes, this blog is a small project and the manual method should be more than enough, but I also play [factorio](https://store.steampowered.com/app/427520/Factorio/) (highly recommend it!), so I _hvae_ to automate everything that is tedious. Yes, this blog is a small project and the manual method should be more than enough, but I also play [factorio](https://store.steampowered.com/app/427520/Factorio/) (highly recommend it!), so I _have_ to automate everything that is tedious.
I also have other projects that I host on my VPS (Virtual Private Server) such my portfolio site [gtz.dk](https://gtz.dk) and a [gitea instance](https://git.gtz.dk/) amongst other things. I also have other projects that I host on my VPS (Virtual Private Server) such my portfolio site [gtz.dk](https://gtz.dk) and a [gitea instance](https://git.gtz.dk/) amongst other things.
## Continuous Integration ## Continuous Integration
@ -159,7 +159,7 @@ Every time we push a commit to the `main` branch, we run the job named `build-an
In the job, we first download our repository with the `actions/checkout@v4` action, then we build the container using `docker build` (we make sure to accurately tag the image), then we log in to the container registry that we want to host the container at using the `docker/login-action@v3` action, and the we simply `docker push` the container image. In the job, we first download our repository with the `actions/checkout@v4` action, then we build the container using `docker build` (we make sure to accurately tag the image), then we log in to the container registry that we want to host the container at using the `docker/login-action@v3` action, and the we simply `docker push` the container image.
Make sure to replace the `git.gtz.dk` website mentions with your own github hosting service (whether self-hosted, or `github.com`) and replace the `gitea/GITEA` mentions with `github/GITHUB` instead. Make sure to replace the `git.gtz.dk` website mentions with your own github hosting service (whether self-hosted, or `github.com`) and replace the `gitea/GITEA` mentions with `github/GITHUB` instead.
Note that the syntax is extemely similar to GitHub Actions - in fact Gitea Actions are trying to be 1 to 1 compatible with GitHub Actions, so it should be relatively straight forward. Note that the syntax is extremely similar to GitHub Actions - in fact Gitea Actions are trying to be 1 to 1 compatible with GitHub Actions, so it should be relatively straight forward.
This setup also gives us the possibility of performing traditional code-review before releasing by using [pull requests](https://docs.gitea.com/next/usage/pull-request?_highlight). This setup also gives us the possibility of performing traditional code-review before releasing by using [pull requests](https://docs.gitea.com/next/usage/pull-request?_highlight).
This should empower us to identify and correct issues (e.g. spelling mistakes or whatever) before they are pushed to the official website. This should empower us to identify and correct issues (e.g. spelling mistakes or whatever) before they are pushed to the official website.
@ -171,7 +171,7 @@ This was the most difficult thing to do. We are _almost_ there.
## Continuous Delivery ## Continuous Delivery
With a docker image readily available, we can automatically deploy the blog when we push it! With a docker image readily available, we can automatically deploy the blog when we push it!
I personally am a big fan of the simplicity of [portainer](https://www.portainer.io/), as it scales really well when doing perosnal server stuff. I personally am a big fan of the simplicity of [portainer](https://www.portainer.io/), as it scales really well when doing personal server stuff.
What we really just need is a simple webhook... Fuck... What we really just need is a simple webhook... Fuck...
@ -203,7 +203,7 @@ Only one small thing - if you are hosting the container on a private registry (l
# Conclusion # Conclusion
PHEW! I started this blog post using words like "simple" and "easy" - but it got a bit out of hand I must admit. PHEW! I started this blog post using words like "simple" and "easy" - but it got a bit out of hand I must admit.
The workflow is very simple now though. You don't have to contiously deal with the mess of deploying your stuff, and you dont have to commit unneccesary autogenerated stuff to git. The workflow is very simple now though. You don't have to contiously deal with the mess of deploying your stuff, and you don't have to commit unnecessary autogenerated stuff to git.
Just focus on writing posts and publish them by merging to `main`. Nice and automated 😁. Just focus on writing posts and publish them by merging to `main`. Nice and automated 😁.
## P.S. ## P.S.