NetAuto Academy

Capstone

Recording the Approved Change

Advanced11 min read

What you'll learn

  • Committing Lesson 2's generated remediation as real Git evidence
  • Reading the approved artifact back from the commit object, not the working tree
  • Why this is not a Git tutorial -- what's assumed, what's new
  • What the commit message records, and why it matters for the final report
🎓 Teach This Lesson

Listen to a guided explanation of this lesson.

Spoken narration isn't supported in this browser.

Evidence before execution

The one rule this lesson exists to satisfy

Nothing gets applied to a device until the remediation is recorded as approved evidence and read back from that record. This lesson is narrow by design: initialize a repo, write the artifact, commit it, read it back. Branching, diffing, merging, and Git's object model itself are all assumed knowledge from Git / NetDevOps -- none of it is re-taught here.

  1. Lesson 2's generated remediationa dict of device -> config line
  2. Write the remediation artifact to disk
  3. Commit it -- the commit message names exactly which devicesrecord_approved_change()
  4. Read the artifact back from the commit objectread_approved_change() -- commit.tree, not the working tree
Quick checkConcept check
What does this lesson assume the learner already knows, without re-explaining it?

The code

capstone_lib.py (Lesson 3 portion)
import git

CHANGE_FILE = "ntp-migration-remediation.cfg"


def init_change_repo(repo_path):
  repo = git.Repo.init(repo_path)
  with repo.config_writer() as cw:
      cw.set_value("user", "name", os.environ.get("GIT_AUTHOR_NAME", "Network Automation Curriculum"))
      cw.set_value("user", "email", os.environ.get("GIT_AUTHOR_EMAIL", "automation@example.local"))
  return repo


def record_approved_change(repo, remediation):
  affected = sorted(remediation.keys())
  # Every affected device gets the identical remediation line in this
  # scenario -- the commit records that one line as the artifact, and
  # which devices it's approved for, in its message.
  config_lines = {remediation[h].strip() for h in affected}
  content = next(iter(config_lines)) + "\n"
  path = os.path.join(repo.working_tree_dir, CHANGE_FILE)
  with open(path, "w") as f:
      f.write(content)
  repo.index.add([CHANGE_FILE])
  message = f"Approve NTP migration remediation for: {', '.join(affected)}"
  return repo.index.commit(message)


def read_approved_change(repo):
  # Reads the approved configuration directly from the commit object,
  # not the working tree -- what gets rolled out is provably what was
  # committed as evidence, not a retyped copy of it.
  commit = next(repo.iter_commits(max_count=1))
  blob = commit.tree / CHANGE_FILE
  content = blob.data_stream.read().decode("utf-8")
  return commit, content

Real, verified code. No credential is hardcoded -- author identity comes from environment variables with obviously-placeholder fallbacks, exactly as every prior Git-touching lesson in this curriculum.

Quick checkIdentify the correct code
Why does read_approved_change() use commit.tree / CHANGE_FILE instead of just opening the working-tree file directly?

Real, verified output

terminal output — real, verified run
--- Approved change committed and read back ---
commit: f3b2bab4
message: Approve NTP migration remediation for: RTR1, RTR2, SW-EOS1
artifact content (read from commit.tree): 'ntp server 10.10.10.2\n'

Real, verified. The commit hash, message, and read-back content are all captured from an actual run -- the message names exactly the three devices Lesson 1 detected and Lesson 2 generated remediation for, nothing more and nothing less.

git log — real, verified
f3b2bab Approve NTP migration remediation for: RTR1, RTR2, SW-EOS1

Real output from git log --oneline against the actual repository this lesson's code created.

Quick checkPredict output
Why does the commit message list "RTR1, RTR2, SW-EOS1" and not all four fleet devices?

What this stage does and doesn't do

Not the same as a real review process

This lesson commits and reads back one artifact locally -- it never opens a pull request, never contacts a real Git remote, and never runs a real review UI. Git / NetDevOps already drew this exact boundary; this lesson inherits it rather than re-deciding it.

Quick checkScenario
A learner asks whether this lesson's Git usage counts as a real code-review process like a team would use on GitHub. What's the honest answer?

Key takeaways

  • This lesson is narrow by design: write the artifact, commit it, read it back -- Git fundamentals, branching, diffing, and merging are all assumed from Git / NetDevOps.
  • record_approved_change() derives its commit message from the actual remediation dict, not a hardcoded device list -- the evidence traces back to Lesson 1's real detection.
  • read_approved_change() reads from the commit object (commit.tree), not the working tree -- proof the rollout will use exactly what was approved.
  • Real, verified run: a real commit hash, a message naming exactly the three affected devices, and read-back content matching what was written.

Done with this lesson?

Next lesson

Canary Rollout and Validation Gates