Profile picture
Sidharth R

Buho CMS

Updated: ⚬ Page views: 72

Contribution in brief

I created a GitHub action workflow that utilizes both Windows and Ubuntu runners. The workflow creates installers for both Windows and Linux. Additionally, it simplifies the release process by automatically including these installers as assets in the final release.

What is Buho CMS?

Buho CMS is a local content management system for static sites. In simple terms it provides a beautiful UI to edit Markdown files (it has more features than that). As of Jun 2023, it supports Hugo, Jkeyll & X static site generators.

  • Tech stack: Flutter

Why you may need to use Buho CMS?

If you have a website based on any of the static site generator frameworks (mentioned above), and you are not comfortable with editing plain markdown files, Buho CMS can be a boon for you. Let’s say your company has a marketing team which is responsible for updating your company website. We can’t expect members of the marketing team to be tech savy. So, they might prefer using Buho CMS to update your website rather than plain Makrdown files.

My contribution

Problem

The release of new versions of the Buho CMS software invovlves creation of installers/binaries for various operating systems (Linux, Windows as of Jun 2023).

Andreas, who is the creator of BuhoCMS, used to take a lot of trouble to create the installers. During my interaction with him, I discovered that, he primarily uses Linux mint for development of Buho CMS. But when he plans to release a new version he has to:

  • Create the linux installers (takes around 5-7 minutes).
  • Get his Windows laptop and do a Git pull. Test the code. Create the installers (10-15 minutes).
  • Transfer the .exe file to Linux Mint (2-3 minutes).
  • Create a new release on GitHub. Upload all installers (3-5 minutes).

I observed that, this laborious and time consuming release of Buho CMS can be automated using GitHub action.

Solution

I created a GitHub action workflow which uses Windows and Ubuntu runners to test (the codebase) and create installers. Then it creates a release with the installers as assets.

The role of the GitHub Actions workflow file (release.yml) can be summarized as follows:

  • The workflow is triggered when a Git tag (in the format v*.*.*) is pushed.
  • The Flutter version is set as an environment variable FLUTTER_VERSION.
  • There are three jobs defined: job1_linux_build, job2_windows_build, and job3_create_release.
  • job1_linux_build runs on Ubuntu 22.04 and performs the following steps:
    • Checks out the repository.
    • Sets up Flutter using the subosito/flutter-action action.
    • Runs a series of commands related to updating system packages, installing dependencies, running Flutter doctor, and building the Linux binaries.
    • Uploads the generated .deb and .AppImage files as artifacts.
  • job2_windows_build runs on Windows 2022 and performs the following steps:
    • Checks out the repository.
    • Sets up Flutter using the subosito/flutter-action action.
    • Runs Flutter doctor and builds the Windows executable.
    • Extracts the latest git tag and sets variables for Buhocms version.
    • Runs Inno Setup to create an installer using the provided script.
    • Uploads the generated .exe file as an artifact.
  • job3_create_release runs on Ubuntu 22.04 and creates a draft release:
    • Downloads all artifacts from the previous jobs.
    • Performs various file operations, including moving and renaming files, to prepare the release assets.
    • Creates a draft release using the ncipollo/release-action action and uploads the release assets.

Overall, this workflow builds cross-platform binaries for Linux and Windows, creates installer packages, and generates a draft release with the built artifacts.