Lab: hand off one MicroBank GitOps owner

Read the handoff as an ownership change

The application should remain present while its configuration owner changes. Deleting an old Application with cascading resource deletion would be a different operation, which is why the first step inspects finalizers. If an ApplicationSet recreates the old Application, deleting the child alone has not completed the handoff.

The new AppProject is a set of restrictions, and the new Application chooses the source, path, revision and destination within those restrictions. The reviewed commit is pinned. That makes the exercise easier to inspect: a later merge is not an automatic instruction to deploy new content.

Expect three different observations: the API accepts your Application object; Argo compares the desired resources; and a requested sync reaches a result. None should be silently treated as the next. The commands below keep the local context explicit, but you still need to inspect that the selected objects belong to this lab.

Prerequisites

The environment lab has rendered successfully. The selected local images and dependencies are working, and the same-case check passes. Reuse the recorded Argo CD installation from Advanced DevOps. If it is absent, follow the pinned-release installation instructions before continuing; measure resource pressure before adding controllers.

Your practice repository must contain the reviewed platform/workloads files at a commit reachable by the controller. A local-only commit is not a remote source. Keep credentials, .local/, state, and raw transaction evidence out of that repository.

1. Establish a clean ownership handoff

Inspect the existing Applications and any Ledger Rollout. If the previous microbank-local Application still owns the two Deployments, remove that Application non-cascading, preserving its resources. First inspect its finalizers:

kubectl --context kind-microbank-advanced -n argocd get application microbank-local \
  -o jsonpath='{.metadata.finalizers}'

If the object is absent, verify it is not managed through a differently named Application. If it has no deletion finalizer and belongs to this lab, deleting that Application preserves the managed workloads. If a resources finalizer exists, use Argo CD's documented non-cascading deletion (argocd app delete ... --cascade=false) through the correct local Argo CD connection; an ordinary delete may also remove the managed resources. Core users can use the documented Core CLI mode with the local kubeconfig.

If an ApplicationSet owns the old Application, change its desired inventory first so it does not recreate the old owner. Stop if you cannot establish ownership. Do not delete Deployments, databases, Secrets, or the namespace for this handoff.

2. Register only the local workload source

Save platform/argocd/local.yaml after replacing the two repository placeholders and the reachable commit. This template intentionally contains no automated sync or cascading finalizer.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: microbank-platform
  namespace: argocd
spec:
  sourceRepos:
    - https://github.com/REPLACE_OWNER/REPLACE_REPOSITORY.git
  destinations:
    - server: https://kubernetes.default.svc
      namespace: microbank
  clusterResourceWhitelist: []
  namespaceResourceWhitelist:
    - group: apps
      kind: Deployment
    - group: ""
      kind: Service
---
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: microbank-platform-local
  namespace: argocd
spec:
  project: microbank-platform
  source:
    repoURL: https://github.com/REPLACE_OWNER/REPLACE_REPOSITORY.git
    targetRevision: REPLACE_WITH_REACHABLE_COMMIT
    path: platform/workloads/overlays/local
  destination:
    server: https://kubernetes.default.svc
    namespace: microbank

kubectl --context kind-microbank-advanced apply -f platform/argocd/local.yaml
kubectl --context kind-microbank-advanced -n argocd get application microbank-platform-local -o yaml

Inspect comparison conditions and the proposed diff before requesting a sync. The project permits only this namespace and these resource kinds. It does not grant a developer permission to edit the project or reduce the controller installation's own permissions.

3. Sync and verify

kubectl --context kind-microbank-advanced -n argocd patch application microbank-platform-local \
  --type merge --patch '{"operation":{"sync":{"prune":false}}}'
kubectl --context kind-microbank-advanced -n argocd get application microbank-platform-local -o yaml
kubectl --context kind-microbank-advanced -n microbank get deployment ledger \
  -o jsonpath='{.metadata.annotations.platform\.learnwithsk\.dev/request}'

After the patch is accepted, confirm the operation result, observed source revision, resource results, and workload readiness. Restart local port-forwards if needed and verify the saved transaction through the earlier Ledger check. Do not create a fresh case as a substitute for persistence evidence.

4. Demonstrate change and recovery

Make the annotation-only request from the environment lab, commit and publish it through your practice workflow, update targetRevision to that exact commit, inspect, then sync. Retain the previous revision. Restore the old annotation through a new reviewed commit and sync again. Record intended and observed revisions and the unchanged image identity.

For a future Rollout-based release, first convert and review the canonical platform desired state and project permissions. Do not have the old Deployment and a Rollout controlling the same intended Ledger workload. The earlier canary's copied snapshot is not the platform source of truth.

Acceptance and cleanup

Confirm that one Application owns the APIs, the new base preserves prior fixes, both annotation changes are traceable, and the same-case check still passes. Keep this Application for the capstone. If retiring it, follow the same non-cascading procedure and document the new owner. Databases and persistent state remain under their existing lifecycle.

Trace an unexpected result

If the annotation did not change, compare the intended commit with targetRevision before changing Pods. If source retrieval failed, inspect repository access. If a project restriction blocked a resource, review the rendered kinds and namespace rather than removing every restriction. If sync succeeds but the saved transaction fails, use application/data diagnosis.

The acceptance result is one known owner and a verified local change/reversal. It does not establish production HA, arbitrary ApplicationSet safety or a finished multi-environment release service. Keep the working owner for the policy and portal exercises.

Sources

Argo CD deletion↗, Argo CD Core↗, Argo CD projects↗, Resource tracking↗.