simp / simp/puppetsync

Scheduled org-wide puppetsync runs (continuous baseline enforcement)

Open
#56 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Ruby
Stars
1
Forks
5
Avg merge
8d 1h
Merged PRs (30d)
4

Description

Goal

Run puppetsync on a schedule (e.g. a cron-triggered GHA workflow) against the whole org, so the baseline is continuously enforced instead of enforced in occasional hand-driven sessions.

Prerequisites

This is the capstone on top of:

  • #49 — full idempotency (no-change repos pass through cleanly)
  • #50 — Renovate-resilient templates (scheduled runs must not clobber Renovate's version bumps)
  • #55 — dynamic inventory from the GitHub API (so the schedule doesn't depend on hand-maintained repolists)
  • #52 — no interactive debugger in the critical path (unattended runs must never hang)

Together those make "safe to run when nothing needs changing" true, which is exactly the property a scheduled run needs.

Sketch

  • GHA workflow on this repo with a schedule: trigger (plus workflow_dispatch: for manual runs), running the sync plan against the org-wide dynamic inventory.
  • Auth via a bot account token; pushes over HTTPS with the token (the push changes using HTTPS basic auth + GitHub token (CI friendly) stretch goal already noted in plans/init.pp).
  • The run's three-bucket summary (PR'd / unchanged / failed) becomes the job output; failures should be loud (issue comment, Slack, or failed job).

Effectively this turns puppetsync into the same kind of continuously-running fleet manager that Renovate already is for dependencies, with the two dividing the labor: Renovate owns versions, puppetsync owns structure.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with plans/init.pp, especially the noted HTTPS basic-auth and GitHub-token path, then review the existing puppetsync flow and the prerequisite issues. Define the scheduled and manually dispatched GitHub Actions workflow around the dynamic org inventory, and use the PR'd, unchanged, and failed buckets as job output with loud failure handling.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, github-actions, ruby
Domain
ci-cd, devops, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.