Posts tagged with "GitHub"

from GitHub to Codeberg

I migrated this blog to GitHub and Netlify back in September 2022. Three years later, I decided to move my (small) number of GitHub repositories to Codeberg as I was impressed by their approach to open source software, transparent communications and I always like to support the underdog.

I'm not a developer and my GitHub repositories were mainly historical versions of my blog over the years placed under version control and as a backup.

My GitHub repos were all basic; single user and didn't include any issues, pull requests and hardly any branches. Consequently, I simply followed the Codeberg documentation and the transition was quick and seamless, preserving all the commit history.

As the test migration went smoothly, I then considered simplifying my blog workflow by removing the dependency on GitHub pages and Netlify. Six months ago, Codeberg provided Codeberg pages which looked to be very similar to GitHub pages.

The blog publishing process previously performed by Netlify's integration with GitHub pages would now be implemented using Codeberg's Woodpecker Continuous Integration (CI) and Codeberg pages.

You had to apply for privileges to use Woodpecker but my request was approved very promptly.

Codeberg helpfully provided examples of Woodpecker files for popular tasks which included a YAML template to publish a Hugo blog from a Codeberg repository to Codeberg pages.

Once I had configured my Codeberg secrets for the Codeberg token and email address and a few iterations, it was working !

Code CI Blog Publish

I liked the Codeberg CI dashboard summary with traffic light icons indicating the success (failure) of each stage together with timing information and the ability to get detailed log information for each stage of the process.

The Codeberg publish process has three stages:

git

The initial 'git' stage fetches the latest changes from the Codeberg repository.

+ git init --object-format sha1 -b main
Initialized empty Git repository in /woodpecker/src/codeberg.org/andyc/yakshaving/.git/
+ git config --global --replace-all safe.directory /woodpecker/src/codeberg.org/andyc/yakshaving
+ git remote add origin https://codeberg.org/andyc/yakshaving.git
+ git fetch --no-tags --depth=1 --filter=tree:0 origin +ed01403b33c60e32ae05f6c81e07fe432ed6100a:
From https://codeberg.org/andyc/yakshaving
 * branch            ed01403b33c60e32ae05f6c81e07fe432ed6100a -> FETCH_HEAD
+ git reset --hard -q ed01403b33c60e32ae05f6c81e07fe432ed6100a
+ git submodule update --init --recursive --depth=1 --recommend-shallow
+ git lfs fetch
Fetching reference refs/heads/main
+ git lfs checkout

build

The 'build' stage builds the site using Hugo and includes the version of Hugo used by Codeberg (useful for debugging issues) and timing information.

+ hugo --minify
Start building sites …
hugo v0.154.5-a6f99+extended linux/amd64 BuildDate=2026-01-11T20:53:23Z
                  |  EN
------------------|-------
 Pages            | 1156
 Paginator pages  |  297
 Non-page files   |    0
 Static files     |  132
 Processed images |    0
 Aliases          |   61
 Cleaned          |    0
 Total in 2612 ms

publish

The 'publish' phase deploys the generated site to Codeberg pages into the 'pages' branch.

+ git config --global user.email $MAIL
+ git config --global user.name "Woodpecker CI"
+ git clone -b pages https://$CODEBERG_TOKEN@codeberg.org/$CI_REPO.git $CI_REPO_NAME
Cloning into 'yakshaving'...
+ cp -ar $HUGO_OUTPUT/. $CI_REPO_NAME/
+ cp .domains $CI_REPO_NAME || true
+ cd $CI_REPO_NAME
+ git add .
+ git commit -m "Woodpecker CI ed01403b33c60e32ae05f6c81e07fe432ed6100a"
[pages 292c34d1] Woodpecker CI ed01403b33c60e32ae05f6c81e07fe432ed6100a
 1388 files changed, 6483 insertions(+), 6483 deletions(-)
+ git push
remote:
remote: Create a new pull request for 'pages':
remote:   https://codeberg.org/andyc/yakshaving/compare/main...pages
remote:
To https://codeberg.org/andyc/yakshaving.git
   7c95fab3..292c34d1  pages -> pages

The final stage was to redirect my domain name from Namecheap to the Codeberg URL. Although, I was aware that the answer is always 'DNS', this configuration change was explained clearly in the Codeberg documentation and worked fine.

reflections on Hugo, GitHub and Netlify

Three years ago I moved my Hugo blog to GitHub Pages and Netlify.

When this end to end process worked successfully, this was brilliant. However, at times, the automated deployment did feel like the game of Mousetrap where a silver ball was released and then proceeded to traverse helter skelters, ride up and down on see-saws, descend zig-zag staircases, cross bridges, trigger catapults, release levers and conquer various hazards before finally launching a bucket to capture a little plastic mouse.

By using GitHub pages and Netlify, I had introduced yet more complexity into the blog publishing process.

Then I decided to add yet another layer of complexity by composing posts in Emacs using Org Mode and using ox-hugo to convert posts to Markdown format.

For the most part, this worked fine which was satisfying and I congratulated myself on my technical wizardry.

However, Hugo occasionally broke after yet another update. Locating and resolving the root cause of these errors was problematic (for me) as the Hugo release notes are very technical and IMHO primarily aimed at Go and/or theme developers. There is hardly ever any section describing breaking (i.e. non backwards compatible) changes or user visible changes.

A random example from the most recent Hugo release (v0.159.0)

This release greatly improves and simplifies management of Node.js/npm dependencies in a multi-module setup.
Replace deprecated site.Data with hugo.Data in tests.
Replace deprecated excludeFiles and includeFiles with files in tests.
Replace deprecated :filename with :contentbasename in the permalinks test.

Failure could be caused by a variety of multiple potential issues.

  1. Was there an error generating the Markdown from the Org Mode source ?
  2. Did Hugo work locally and generate the HTML for the site successfully ? This was normally the most frequent reason for the failure. An Arch update would often update the Hugo package and Hugo updates were quite frequent.
  3. Did the PaperMod theme need updating to reflect the most recent changes in Hugo ?
  4. Do other popular Hugo themes (Ananke) function without any issues ?
  5. Assuming the local Hugo site works, did the push to GitHub work ? Check the recent updates to the GitHub repository.
  6. Did Netlify then get triggered correctly by the GitHub updates?
  7. Did the Hugo build process complete successfully on Netlify ? What version of Hugo is Netlify using ? Is this identical (or compatible) with the locally installed version of Hugo ?

After yet another issue following a Hugo upgrade, I got increasingly frustrated with this frictionless blogging process that was anything but. I was now spending more time fixing my static (sic), unchanged blog instead of writing any new posts.

Once again, I started to consider using an alternative static site generator. After all, I already had migrated my content to each of the popular SSG's I evaluated last year.

My mind was made up. I was going to do it. Just a question of selecting an SSG and actually doing it.

And then Dave Pearson came along and spoiled everything by creating BlogMore...

from GitHub pages to Amazon S3

Although hosting on GitHub pages is an excellent option, I decided to move this blog to Amazon S3, mainly because I have used S3 before. Also GitHub pages only supports a limited set of Jekyll plugins and I wanted more flexibility to add any plugin and (potentially) run a different version of Jekyll.

I also took the opportunity to switch the theme to the rather minimalistic but stylish Poole and installed the useful s3website utility to automatically synchronise the static site to Amazon S3. As you are charged for upload/download traffic, an intelligent sync process (rather than uploading everything) for deployment is important.