InkProject Blog Github Workflow
Bey Bey Hugo, welcome Ink
This blog is no longer generated by Hugo. The Hugo Static Content Generator has been in use for a long time, but over the past few weeks, I’ve been exploring alternatives. I went through several and eventually settled on InkProjekt.
After the initial tests, more and more posts were gradually migrated. During this process, the first steps towards Docker and Kubernetes were also taken for both Ink and this blog. I’ve been working with Docker and Kubernetes for a few years now..
Write, publish, build, and deploy
The sequence is clear, as always. A new post is written, or as now with Ink, copied. After that, ink publish is executed. All files from the public directory are copied to html, allowing a Dockerfile for Nginx to populate the html directory with the new content. Docker Push into the Docker Registry, followed by a kubectl set image…. The new version was online.
These were initially manual steps. Just a few shell scripts.
GitHub Actions
After everything ran smoothly, it was time to automate the entire process. Create a post or page, git add, commit, push, and GitHub Action would handle the page assembly, building Docker images for all platforms, and managing the HelmChart.
Initially, everything was in one Git repo, so first off, the Helm Chart was moved into its own. After a push, the workflow took care of the following steps:
1. Repo checkout
2. Increment Semantic Release version
3. Save version in GitHub Environment
4. Create page with ink publish
5. Package pages into Docker images for all platforms
6. Combine Docker images into a MultiPlatform image
7. Push Docker image to the registry
8. Checkout Helm Chart repo
9. Create Helm Chart with the semantic version
10. Push Helm Chart to the Helm Chart Museum
11. Deploy Helm Chart to the Kubernetes cluster.
Since everything ran perfectly, it was time to split things up.
As everything, except for the Helm Chart, was in one repository, it made parts of it hard to reuse for other websites or blogs. Thus, the first step was to place the content into its own GitHub repo.
With InkProject, not only the Markdown files containing the content are found in the Source, but also the images. These were promptly separated out and copied into their own repo, ensuring that only the Markdown files for the blog content remained in a single repo.
As for themes, they were given their own Helm repository. The same was done for the foundational components of InkProject. The binary files — yes, files, because I included direct arm, amd, etc., in case the GitHub Runners operate on different platforms — along with the configuration, were also separated.
The GitHub Workflow was then adjusted.
The workflow now starts in the ink-blog repo. It sequentially pulls the following repositories:
* ink-content
* ink-images
* ink-theme
* ink-html
These are placed in the source, source/images, theme, and html directories, respectively, thus maintaining the directory structure required by InkProject.
In the next step, the blog is created using ink publish, after which the files are copied to the html directory. The html directory is its own GitHub repo, so we switch to it and execute git add, commit, and push. This way, I have the new content stored in its own repo.
The rest is discarded from the workflow, and in the next step, Docker images for multiple platforms are created. For this, the ink-html repo is needed and thus is checked out in the steps.
All Docker images are then merged into a MultiPlatform image and uploaded to the Docker Registry.
During all these steps, Semantic Release is used, which means both Docker images and Helm Chart are automatically tagged with the correct version.
Finally, the Helm Chart is checked out, created with the semantic version, and the image is set via the values.yaml. The Helm Chart is pushed to the Chart Museum, and then installed in the Kubernetes cluster.
Workflow, the 3rd version.
The workflow is good, and one could leave it as it is. However, since I manage the content in its own repository, I would always have to first create or modify the content and then push it. Then I’d have to do the same with the ink-blog repo to trigger the pipeline.
No, there’s a different way to do it.
Content with its own Action
The Action in the Content Repo doesn’t do much. It doesn’t even assemble anything. It simply triggers the other pipeline in the ink-blog repo, which then handles everything else.
Content triggers ink-blog; ink-blog checks out ink-content and other repos, compiles everything, creates images and a Helm Chart, and deploys everything in Kubernetes.
It’s as simple as that.
The advantage is: I can even create and modify content from my phone. I can also expand this for other blogs and websites. Only the content for individual sites is then stored; the build with other data always comes from the same repos. It’s not set up yet, but the foundation for it is already in place.