🔄 Topic

Debugging and fixing the blog’s own GitHub Pages publishing so a batch of finished posts could actually go live.

🎯 Goal

Get the publishing pipeline reliable: posts written, posts deployed, and older posts restored into the repository.

🛠 What I Did

I had a batch of finished daily posts that would not publish correctly. Instead of fighting it post by post, I treated the blog like any other production system: inspected the Pages deployment, fixed the publishing configuration through a proper pull request, added the missing older post files back into the repository, and then shipped the whole backlog of posts in one verified push. The learning log itself became the system under investigation.

Main areas covered:

  • diagnosing a Pages deployment that silently misbehaved
  • Jekyll configuration and post conventions
  • fixing the pipeline via a reviewed pull request
  • restoring older post files into version control
  • publishing a backlog batch and verifying it live

🔗 Key Cybersecurity Connections

A publishing pipeline is a small CI/CD trust chain: repository, build, artifact, live site. If it fails silently, you believe you shipped something you did not — the same class of problem as a security fix that never reached production.

🔍 Investigation Questions

  • Where exactly does the pipeline decide what gets published?
  • Did the build fail, or did it succeed while excluding content?
  • Is every published post tracked in version control?
  • Does the live site match the repository state?
  • What would tell me sooner next time?

🚨 Detection Opportunities

Potential monitoring ideas:

  • deployment runs that succeed with fewer output files than expected
  • drift between repository content and live pages
  • failed or skipped Pages builds
  • configuration file changes in the publishing path
  • posts present locally but missing from the feed

Example:

project=juribuora-github-io
change_type=pages_pipeline_fix
risk_area=silent_deployment_drift
triage=compare_repo_content_with_live_output

🧭 MITRE ATT&CK Techniques

Possible mappings depending on confirmed behavior:

  • T1195 — Supply Chain Compromise
  • T1565 — Data Manipulation
  • T1078 — Valid Accounts

🗺 Visual Investigation Diagram

Posts written
    ↓ Pipeline misbehaving
    ↓ Deployment inspected
    ↓ Fix via pull request
    ↓ Backlog published and verified

⚠ Challenges

The challenge was that nothing was loudly broken. The build ran; the content just did not appear the way it should. Silent failure is harder to notice than a red X.

📚 What I Learned

I learned that the systems I use to document my learning deserve the same operational scrutiny as the systems I write about. “It deployed” and “it is correct and live” are different claims.

➡ Next Steps

  • Check the live feed after every batch of posts
  • Keep all post files, old and new, in version control
  • Note the pipeline quirks in the repository README
  • Reuse this drift-checking habit on client sites

🧠 Reflection

This was useful because it collapsed the distance between studying deployment trust boundaries and experiencing one fail on my own project.

🧩 Lessons Learned

What worked

Treating the blog as a production system with a real investigation.

What broke

The publishing path between finished posts and the live site.

Why it broke

Configuration and content conventions the pipeline enforced but I had not verified.

Fix / takeaway

Verify what a pipeline actually publishes, not just whether it ran.

📈 Skill Progression Context

This supports my cybersecurity progression because silent pipeline drift is exactly how unpatched artifacts and stale deploys happen in real organizations.

😄 TL;DR

The blog about verifying systems needed verifying.