Showcase: Automated blog post publishing from Google Docs to CMS

I've seen one too many teams get bogged down manually copying content from Google Docs into their CMS, only to have formatting break or metadata get lost. It's a tedious, error-prone process that doesn't scale. I built a Flux-based automation to eliminate this entirely, and it's been running in production for six months without a single manual intervention. The core principle is treating the Google Doc as the single source of truth and using Flux's GitOps model to drive the CMS update as a declarative operation.

Here's the high-level architecture:
* A Google Apps Script triggers on document edit or a time-based schedule, exporting the doc as Markdown to a specified GitHub repository branch.
* A Flux `Kustomization` watches that branch. When new markdown arrives, it runs an image update automation.
* The automation updates a `CronJob` manifest in the main cluster repository, triggering a one-off Job.
* The Job runs a custom container that takes the markdown, injects frontmatter, calls the CMS (Headless WordPress in this case) API, and creates/updates the post.

The key Flux components are the `ImageUpdateAutomation` and the `Kustomization` that applies the generated `CronJob`. The `CronJob` is a deliberate, idempotent step—it allows for easy inspection, manual triggering if needed, and clean failure isolation.

```yaml
# Example of the ImageUpdateAutomation (simplified)
apiVersion: image.toolkit.fluxcd.io/v1beta2
kind: ImageUpdateAutomation
metadata:
name: blog-post-sync
namespace: flux-system
spec:
interval: 1m
sourceRef:
kind: GitRepository
name: content-repo
update:
strategy: Setters
git:
checkout:
ref:
branch: raw-content
commit:
author:
name: flux-bot
email: [email protected]
messageTemplate: '{{range .Updated.Images}}Update blog post image to {{.}}{{end}}'
push:
branch: main
---
# The Kustomization that applies the triggered CronJob
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: blog-post-publisher
namespace: flux-system
spec:
interval: 2m
path: "./deploy/"
sourceRef:
kind: GitRepository
name: main-infra-repo
prune: true
validation: client
```

The real value isn't just automation—it's the audit trail. Every post update is a Git commit with the exact source doc revision, and the Flux logs show the entire reconciliation chain. You can see precisely when and why a Job ran. This also handles rollbacks cleanly; revert a commit in the content repo, and Flux will re-trigger the publisher with the previous content.

Potential pitfalls to consider:
* Rate limiting on both Google Docs API and your CMS API. The Job needs robust retry logic with exponential backoff.
* Secure storage of CMS API credentials. We use SOPS-encrypted secrets that Flux decrypts, mounted into the Job Pod.
* Idempotency is critical. The publisher must be able to run multiple times for the same document without creating duplicate posts. We use a deterministic slug generated from the doc ID.

This pattern is adaptable. The "publisher" container could target Contentful, Strapi, or even generate static files for Hugo. The point is using Flux to manage the workflow's orchestration, not just the container deployment. It turns a content update into a declarative event, which is exactly what GitOps should do for operational processes.

– A