The first GitHub Actions workflow I shipped was a paste from a README. Thirty lines of YAML. Green check on the pull request. I felt briefly competent.
Two weeks later the job failed on a matrix I had never looked at. I opened the file, stared at runs-on, needs, and a string of ${{ }} expressions, and realized I could not explain a single step out loud. The pipeline still "worked" until it didn't. I had shipped muscle memory, not understanding.
If that sounds familiar, you are not bad at DevOps. You learned Actions the way most of us do: find a snippet, tweak the name, merge. Here is a slower path that actually sticks.
Stop collecting workflows. Collect questions.
Before you open another "ci.yml" gist, write down what you want the repo to do when something happens. Push to main? Open a PR? Tag a release? Nightly?
Actions is event-driven automation. The YAML is just the spelling. If you cannot name the event and the outcome in one sentence, you are not ready for the file yet.
My first useful sentence was: "On every pull request, run the tests and tell me if they fail." That one job taught me more than five copy-pasted deploy pipelines.
Learn the four nouns in order
Most tutorials dump the whole file on you. Unpack it instead.
Events are the triggers: push, pull_request, workflow_dispatch, a schedule. Change only the event and leave the job the same. Watch when it runs and when it doesn't. That single experiment makes the top of every workflow file stop feeling magical.
Jobs are units of work that can run in parallel or wait on each other with needs. Start with one job. Add a second only when you have a reason, like "lint can fail separately from tests."
Steps are the lines inside a job. Some call a published action (actions/checkout, actions/setup-node). Some are plain run: shell. Read each step and ask: what files exist before this line, and what exists after? If you cannot answer, the step is cargo cult.
Runners are the machines. ubuntu-latest is fine for learning. You do not need self-hosted anything until you understand why a job needs a specific OS or more disk.
Ignore caching, artifacts, environments, and reusable workflows until those four nouns feel boring. They are power tools. Power tools on a foundation of paste are how you get a green check that means nothing.
Make one tiny workflow by hand
Create a throwaway repo. Add .github/workflows/hello.yml with almost nothing:
name: hello
on: push
jobs:
say:
runs-on: ubuntu-latest
steps:
- run: echo "still here"
Push. Find the run in the Actions tab. Click through the log. Then break it on purpose: typo the shell, change on: to pull_request, add a second step that lists the workspace before and after actions/checkout@v4.
That last change is the one that clicked for me. Empty runner, then checkout, then your files appear. Suddenly every tutorial's first step stopped looking like ceremony.
Grow the file only when a real need shows up. Need Node? Add setup-node and print the version. Need tests? Call your test command. Need a secret? Put one in the repo settings and reference it once, then rotate it. Each addition should answer a question you already have.
Read docs and videos like you will forget them
You will forget them. That is normal. The mistake is treating a twenty-minute Actions explainer as a one-time watch, or a docs page as something your browser tabs will babysit forever.
When you find a good piece (the official "Understanding GitHub Actions" guide, a talk on expressions, a walkthrough of workflow_call) save it somewhere you will see again. Skimming twice in one evening is not the same as answering a question about needs three days later.
This is the gap Recl fills for me while I learn tooling like this. I save the docs page, the YouTube explainer, a Reddit thread, or a Substack post from the share sheet or the Chrome extension (Ctrl/Cmd+Shift+S, side panel, or right-click). Recl builds a short AI summary with a TL;DR, key takeaways, and chapters, drops the save into Library topics, and later nudges me with a recall question so the idea comes back on a schedule instead of vanishing into a bookmark folder.
When I am mid-debug and cannot remember whether workflow_dispatch inputs show up under github.event or somewhere else, I ask my library and get an answer grounded in what I actually saved, with sources. The Today tab keeps the next recall pass visible. Folders and auto topics keep "GitHub Actions" separate from the random tutorials I saved last month.
I still keep a scratch repo for breaking YAML. Recl is not a CI runner. It is where the explanations live so I am not re-watching the same intro every time a job turns red. Public saves on library.recl.app show how a long tutorial looks after the summary step.
A practice loop that beats another gist
Pick one concept per day for a week: events, jobs and needs, checkout and the workspace, secrets, matrices, artifacts, then rewrite one real job from memory and diff it.
After each experiment, write two sentences in your own words and save the doc or video that taught you. When a recall nudge asks later, answer without opening the YAML. If you blank, re-open the summary, not a fresh gist.
The goal is not a perfect enterprise pipeline. It is reading a failing step and knowing which noun broke.
Ship understanding, not paste
Copy-paste gets you a badge on the PR. Understanding gets you a fix at 11pm when the matrix explodes on a version you forgot you pinned.
Name the event. Build one job by hand. Add steps only when you can explain the filesystem before and after. Save the tutorials worth keeping, and practice recalling them so the next snippet you touch is a choice, not a prayer.
Save what matters. Recall it forever.
About the author
Asutosh Pattanayak builds Recl — save docs, videos, and notes from anywhere, get a short summary, and get nudged to recall the parts that matter so the next workflow you write is yours.
Top comments (0)