PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The fastest way to learn GitHub Actions is to build one small workflow in a test repository, work out what each line does, and read the run log when something fails. The story behind this title, a first attempt that stalled and a second attempt that worked with AI assistance, is the author’s own account. The events in it are not independently verified here, and nothing in this guide claims that AI assistance improves learning outcomes in general. What follows is the hands-on path that the account points toward, with the parts you can check yourself.
What GitHub Actions does
GitHub describes Actions as a CI/CD platform for automating build, test and deployment work. GitHub’s Workflows documentation gives a mental model that is worth memorising before you write any YAML. A workflow is nested from the outside in:
| Part | What it is | Where it appears in the YAML |
|---|---|---|
| Event | What starts the workflow: a repository event such as a push, a manual trigger, or a schedule | on: |
| Workflow | The YAML file itself, stored in .github/workflows |
The whole file |
| Job | A unit of work that runs on a runner | jobs: |
| Runner | The machine that executes a job | runs-on: |
| Step | A script to run or a reusable action to invoke, executed in order inside a job | steps: with run: or uses: |
Before you start
GitHub’s Quickstart for GitHub Actions assumes the following, and you should confirm each one before you begin:
Recommended Free Tools
- A GitHub repository you are allowed to push to. A throwaway repository is the safest place to experiment.
- Basic familiarity with repositories, commits and pull requests.
- Actions enabled for that repository. If it is turned off, check the repository’s Settings tab, then Actions, then General.
- A way to edit a text file, either the web editor on GitHub or a local editor with Git.
Build your first workflow
- Open your repository on GitHub and select Add file, then Create new file.
- In the file name box, type
.github/workflows/hello.yml. Each slash creates a folder, so this produces theworkflowsfolder inside.github. - Paste the workflow shown below.
- Commit the file to your default branch, or commit to a new branch and open a pull request if you want to practise that flow too.
- Select the Actions tab in the repository. The run should appear in the list shortly after the push.
- Select the run, then the job named
hello, then expand each step to read its output.
name: Hello workflow
on: push
jobs:
hello:
runs-on: ubuntu-latest
steps:
# Copies your repository into the runner. Use the version shown in GitHub's quickstart.
- uses: actions/checkout@v4
- name: Print greeting
run: echo "Hello from GitHub Actions"
- name: Show runner details
run: |
uname -a
pwd
The @v4 on the checkout line is an example. Copy whichever major version the current quickstart shows, because versions of official actions change over time.
#1 Best Overall
Read each piece before you add complexity
The trigger: on
on: push tells GitHub to start the workflow whenever someone pushes a commit to the repository. Changing it is the first experiment worth trying. Replace it with on: workflow_dispatch to get a manual Run workflow button on the Actions tab, then compare the two behaviours.
The runner: runs-on
runs-on: ubuntu-latest asks GitHub to run the job on a GitHub-hosted Ubuntu runner. Each job starts on a fresh runner, so a file you create in one job is not available in another unless you pass it along explicitly.
The steps: run and uses
A step with run executes a shell command. A step with uses invokes a reusable action, such as the checkout action in the example. Steps run in the order they are written, and a failing step normally stops the job, which is why the log for a failed run is usually the most useful place to look.
Free tools Windows power users keep installed
One-click scans. No signup required.
Common first-attempt failures
- The workflow never appears on the Actions tab. The file is probably not directly inside
.github/workflowsat the repository root, or its extension is not.ymlor.yaml. - The file exists but nothing runs. Check that the
on:trigger matches what you actually did. Scheduled workflows run from the default branch, so a schedule on a feature branch will not fire. - The run fails before any step starts. This is usually a YAML syntax error, most often from indentation. Use spaces, not tabs, and keep each level indented consistently. Read the error message literally; it normally points to the line that failed to parse.
- A secret is empty or missing. Create it under Settings, then Secrets and variables, then Actions, and refer to it as
${{ secrets.YOUR_SECRET_NAME }}. Do not paste credential values into the YAML itself. GitHub’s Workflow syntax for GitHub Actions reference covers the secrets context.
Where AI fits, and where to stop trusting it
GitHub’s tutorial Develop agentic workflows in GitHub Actions describes a documented approach: use a coding agent to write and refine the instructions for a workflow, compile the workflow, then review the files it generates. That is a documented option. It does not show that the approach teaches more effectively than other methods, and the author’s account of a successful second attempt should be read as one person’s experience.
Quick Recap
A practical way to use an assistant
- Paste in a workflow you already wrote and ask for a line-by-line explanation. Check the explanation against the Workflows documentation.
- Ask for one small change, such as adding a second step, and predict what the run log will show before you commit.
- Commit one change at a time, so that a failure points to a single cause.
- When the assistant suggests a new keyword or option, look it up in the official syntax reference before accepting it.
What to check in generated YAML
- The trigger matches your intent. A
pushtrigger with no branch filter runs on every push to every branch. - Secrets are referenced through the secrets context and not written into the file.
- Each
uses:line points to an action you recognise and trust, and is pinned to a version you have checked. - The workflow runs successfully and the log says what you expected. A generated file that looks correct but fails in the Actions tab has not taught you anything yet.
Next steps after the first green run
- Add a pull request trigger. Change or add
on: pull_requestso the workflow runs against proposed changes before they are merged. - Add a second job. Give it a
needs:entry that names the first job, so it runs only after the first succeeds. - Introduce a secret. Store a dummy value, reference it in a step, and confirm that the log masks it.
- Try a reusable action. Replace a shell command with a
uses:line for an action from GitHub’s marketplace, and read its documentation before you run it.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
