Your First Github Workflow

Time to stop reading about workflow files and actually trigger one. This chapter builds the smallest possible workflow — one job, one step — so you can watch the entire pipeline from push to running job with nothing else competing for your attention.

Create The Workflow File

In your actions-practice repository, create the workflows directory and a new file inside it:

mkdir -p .github/workflows

Create .github/workflows/hello.yml with this content:

name: Hello World

on:
  push:

jobs:
  greet:
    runs-on: ubuntu-latest
    steps:
      - name: Say hello
        run: |
          echo "Hello from GitHub Actions!"
          echo "This job was triggered by: $GITHUB_ACTOR"
          echo "Repository: $GITHUB_REPOSITORY"
          echo "Current time on the runner: $(date)"

A few things worth noticing before you push this:

• on: push with nothing underneath it means “any push, to any branch.” That’s intentionally broad for this first workflow — you’ll narrow it down in later workflows once you understand the trade-offs.
• $GITHUB_ACTOR and $GITHUB_REPOSITORY are environment variables GitHub automatically sets on every runner. You didn’t define them; they just exist for every job to read.
• $(date) is plain shell command substitution — a reminder that a run step is genuinely just a shell running on a real (if temporary) Linux machine.

Push It And Watch It Run

git add .github/workflows/hello.yml
git commit -m "Add hello world workflow"
git push

The instant that push lands on GitHub, the workflow fires. Go to your repository on github.com and click the Actions tab. You should see a new run appear, usually within a few seconds, labeled with your commit message.

Click into the run, then click the greet job, then expand the Say hello step. You’ll see the exact output of those four echo and date commands, timestamped, exactly as if you’d run them in a terminal yourself — because that’s essentially what just happened, on a machine GitHub spun up for you and will tear back down the moment the job finishes.

Trigger It Again

Make a trivial change — edit the echo text, or just add a comment — and push again:

git commit --allow-empty -m "Trigger another run"
git push

Notice a second run appears in the Actions tab, completely independent of the first. Every push creates its own run, with its own fresh runner, its own logs, and its own history. Nothing carries over between them — which is exactly the behavior you want from CI, and something worth sitting with before the next few chapters start making these workflows do more.