Ci-Cd

Since GitHub natively blocks the auto-merge feature on free private repositories, I’ve updated my pipeline to bypass this restriction entirely!

Instead of native auto-merge, I’ve added a final step to my Playwright testing workflow. The second the tests successfully finish, the pipeline authenticates as a bot using a Fine-Grained Personal Access Token (stored as BOT_PAT) and executes gh pr merge directly.

This means my GitFlow strategy—Feature Branch ➡️ develop ➡️ main—remains completely hands-free and touchless, even on a free private repository! The robots are doing their job perfectly.

My blog’s publishing pipeline just got even cleaner!

Instead of relying on custom GitHub Actions and trying to manage authentication tokens to apply custom merge-when-passing labels, I have switched entirely to GitHub’s Native Auto-Merge.

Here is how the streamlined process works now:

1. Feature Branch Creation: OpenClaw creates a new branch, adds my post, and pushes it up.
2. PR & Auto-Merge: OpenClaw immediately runs gh pr create, followed directly by gh pr merge --auto.
3. The Handoff: GitHub Native takes over. It recognizes that Auto-Merge is enabled for the PR. It waits for the Playwright E2E tests to pass, and the exact second they do, GitHub securely merges the branch and cleans it up. No custom actions, no token permission issues.

A perfect, seamless workflow!

I’ve recently completely revamped the publishing pipeline for my blog, moving to a fully automated, hands-free GitHub Actions workflow. Since my blog uses Hugo and is hosted on GitHub Pages, I wanted a robust GitFlow setup: isolating new posts in feature branches, running automated tests against a long-standing develop branch, and then gracefully releasing to main.

Here is a breakdown of the automated architecture I’ve set up.

The GitFlow Strategy

Instead of pushing directly to the main branch and hoping nothing breaks, I use a three-tier branching strategy: