###############################
Sun Oct 10 02:16:17 PM EDT 2021
###############################

I don't know what the big deal is...

Well, I guess I do.

I look at different software developer, devops, and
devsecops job listings, and I see the CI/CD requirements.
What do they mean by this? Well, aside from setting up
environments, the rest is operating tools; so, how many
years of experience with this tool and how many years of
experience with that tool, and ...?

I set up a gitea instance so (1) I could share some code in
different languages with folks who might want a sample, and
(2) because it would be a lot of fun if any project that I
worked on for my own needs actually found some other
interested folks. It's self-hosted because, well, why not?
I'm already fairly skilled with the the network plumbing,
hosting services, and so forth.

Part of those self-hosted services was this gopher service.
My workflow was (1) write on the laptop, (2) git push it to
my gitea gopher site repository, then go out to the front
end with public access and go a git pull to update. In the
back of my head I knew it would be possible to automate
that. I figured I'd just cron job a few git pulls per day
and be done with it.

Thinking through that a bit, there's the issue of ssh keys.
I have a dedicated ssh key for doing all of my gitea work,
but that's a lot of access... and I probably don't what to
do be doing all that work under that user account anyway.

I knew there are solutions, so it only took a few minutes to
find gitea's webhooks and deploy keys. Web hooks will send a
POST request wherever you want to send it with details about
whatever triggered it -- cool!. And deployment keys? An ssh
key with read-only access to the specific repository?
Perfect.

Create a system user without login, but with a home
directory. Write maybe a four-line python Flask server to
listen for the POST and to execute a shell script. The
system user gets the deployment key, so set up his
ssh/config to use it when contacting gitea. Let's use
gunicorn to run the service, and let's set up a systemd
service file to get it running. Update the network plumbing,
and ... done!

So, no: This service doesn't check the validity of the POST
request or check that it's a specific action. For now, it's
enough that there's a secure channel between the gitea
service and the POST listener, and this repository is only
being used in this particular way -- no branches outside of
master, for instance. For now, it's only moving forward, not
rolling back. Good enough for now.

Back when I used to be in hiring loops, I'd look for the
"Green Berets:" Not single language specific folks, and by
all means not tool operators. Tell me how you would attack
the problem. Tell me where you'd install the hooks. Describe
the high-level flow, maybe an algorithm. Use pseudo-code or
plain English. Tell me about networking -- routers,
firewalls, switches, VLANs, VPNs, ... Tell me about NAT.
Tell me about team workflow. If you're a pro, you've done
this stuff in /some/ language and used /some/ equipment, and
you can learn another languge or some other equipment.

I'm wishing I found more of that out there now.