Skip to content

Adds a companion guide for Lesson 3 of the GitOps Tutorial Series - #32

Draft
alexcreasy wants to merge 2 commits into
streamshub:lesson-1-companionfrom
alexcreasy:lesson-3-companion2
Draft

Adds a companion guide for Lesson 3 of the GitOps Tutorial Series#32
alexcreasy wants to merge 2 commits into
streamshub:lesson-1-companionfrom
alexcreasy:lesson-3-companion2

Conversation

@alexcreasy

@alexcreasy alexcreasy commented Aug 13, 2026

Copy link
Copy Markdown
Collaborator

This is an initial draft, as with the other lessons I'll add in hyperlinks and some instructions for checking out the repository before converting to a full PR.

Closes #24

Signed-off-by: Alex Creasy <alex@creasy.dev>
@alexcreasy alexcreasy linked an issue Aug 13, 2026 that may be closed by this pull request
Signed-off-by: Alex Creasy <alex@creasy.dev>

@tomncooper tomncooper left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just a couple of suggestions.

Yet underneath, the system is broken.
The configuration you pushed describes something the underlying platform cannot actually do.
This is not a hypothetical edge case.
It is a failure mode that every team running operator-managed infrastructure will encounter sooner or later.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
It is a failure mode that every team running operator-managed infrastructure will encounter sooner or later.
It is a failure mode that every team running production infrastructure will encounter sooner or later.
Often, you will set-up tests in you CI system to check the configurations for common errors before they are pushed to the CD system.
However, you can't test for everything and sometime issues can slip through, valid changes can be made in error or people can simply change their mind.

It is a failure mode that every team running operator-managed infrastructure will encounter sooner or later.

This lesson tackles that scenario head-on.
You will learn how to distinguish between a successful sync and a genuinely healthy deployment, and when things go wrong, how to roll back safely using Git alone.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
You will learn how to distinguish between a successful sync and a genuinely healthy deployment, and when things go wrong, how to roll back safely using Git alone.
You will learn how to distinguish between a successful sync and a genuinely healthy deployment, and when things go wrong, how to roll back safely with a single commit.

## Sync Status vs Health Status

ArgoCD tracks two independent statuses for every Application it manages.
*Sync status* tells you whether ArgoCD successfully applied the manifests from your Git repository to Kubernetes.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we calling them "manifests" or "configurations". Are configurations upstream of manifests? Is it config > kustomize > manifests?

I am not saying that is wrong, just want to make sure we are being consistent.


Consider a configuration change that the Kubernetes API accepts but the platform rejects.
The Custom Resource is stored, so ArgoCD reports `Synced`.
But the operator that manages that resource inspects the change, determines it violates a platform-level constraint, and marks the resource as not ready.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
But the operator that manages that resource inspects the change, determines it violates a platform-level constraint, and marks the resource as not ready.
But the operator that manages that resource inspects the change, determines it violates a constraint of the system it manages, and marks the resource as not ready.


There are two ways to undo a commit in Git, and they have very different implications in a GitOps context.

`git revert` creates a new commit that applies the exact inverse of the target commit.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
`git revert` creates a new commit that applies the exact inverse of the target commit.
`git revert <commit hash>` creates a new commit that applies the exact inverse of the target commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Companion guide lesson 3 tutorial

2 participants