Quarter of the way in, and Day 25 landed on a theme I did not expect: the last step of both tasks can only be completed by a person. Not a flag, not a retry, not a smarter command. A human has to decide something, and until they do, the system waits.
One Git task, one AWS task. Merge a feature branch back into master and deal with a conflict, then launch an EC2 instance and put a CloudWatch alarm on it. The tasks come from the KodeKloud Engineer platform.
Merging: two kinds, and Git picks for you
The first thing to get straight is direction. A merge runs from the branch you are merging into. You stand on master and pull the feature branch towards you, not the other way round.
git switch master
git pull # make sure master is current first
git merge feature-x
What happens next depends on something you did not choose. If master has not moved since the branch was created, Git performs a fast-forward: it simply slides the master pointer up to the tip of your branch. No merge commit exists. The history looks like the branch never happened.
If both branches have new commits, Git does a three-way merge and creates a merge commit with two parents, recording that two lines of work came back together.
That difference matters more than it sounds, because a fast-forward erases the shape of what you did. If you want the record kept:
git merge --no-ff feature-x
git log --graph --oneline --all --decorate
--no-ff forces a merge commit even when a fast-forward was available. It costs one commit and buys a permanent, readable record that a branch existed and when it landed. Plenty of teams require it for exactly that reason.
And then, sooner or later, this:
CONFLICT (content): Merge conflict in app.py
Automatic merge failed; fix conflicts and then commit the result.
A conflict is not an error, and it is not Git failing. It is Git refusing to guess. Two branches changed the same lines, and there is no correct answer available from the data alone, so it stops and hands the decision to you. That is the right behaviour, and it is worth reframing it that way, because the panic response is what causes damage.
git status # exactly which files are stuck
# Open each one, find the markers, decide what the file should say:
# <<<<<<< HEAD the version already on master
# =======
# >>>>>>> feature-x the version from your branch
git add app.py # staging IS the resolution signal
git commit
Editing the file is not enough. git add is how you tell Git you have decided. Until the file is staged, the merge is still in progress no matter how clean the file looks.
And the safety valve nobody mentions until you are already sweating:
git merge --abort
That puts everything back exactly as it was. Knowing it exists is the difference between a conflict being a problem and a conflict being a nuisance.
The alarm: a threshold, a duration, and a link somebody has to click
The AWS side was launching an instance and alarming on its CPU. The alarm itself is one command, but two of its arguments carry all the meaning:
aws cloudwatch put-metric-alarm \
--alarm-name nautilus-high-cpu \
--namespace AWS/EC2 --metric-name CPUUtilization \
--dimensions "Name=InstanceId,Value=$INSTANCE_ID" \
--statistic Average \
--period 300 --evaluation-periods 2 \
--threshold 70 --comparison-operator GreaterThanThreshold \
--alarm-actions $TOPIC_ARN
--period is the length of one measurement window in seconds. --evaluation-periods is how many consecutive windows have to breach before the alarm fires. Together, 300 and 2 mean CPU must stay above 70% for a full ten minutes. That is not pedantry, it is the difference between an alarm that tells you something and an alarm that screams every time a cron job runs and gets muted within a week.
--dimensions is what scopes the metric to one instance. Leave it off, and you get the aggregate across everything reporting that metric, which is rarely what anyone means.
The alarm notifies through an SNS topic, and an SNS email subscription does nothing at all until the recipient clicks a confirmation link:
aws sns subscribe --topic-arn $TOPIC_ARN \
--protocol email --notification-endpoint ops@example.com
aws sns list-subscriptions-by-topic --topic-arn $TOPIC_ARN
If that comes back PendingConfirmation, your monitoring is decorative. The alarm will transition to ALARM exactly as designed, publish to the topic exactly as designed, and reach nobody. Every command succeeded. Nothing works.
Two more things worth knowing. A new alarm sits in INSUFFICIENT_DATA until enough data points arrive, which is expected rather than broken. And memory and disk usage are not default EC2 metrics at all, because the hypervisor cannot see inside the operating system. If you want those, you install the CloudWatch agent.
The step only a person can take
Both tasks end the same way. Git stages a conflict and waits for a human to say what the file should be. CloudWatch wires up a notification and waits for a human to confirm they want it. In both cases, everything upstream reports success, and the whole thing is inert until somebody does the last small thing.
So here is the Day 25 question. How much of your setup currently reports green while quietly waiting on a step nobody has taken?
Day 25 down. Seventy-five to go.
Top comments (0)