DEV Community: Julie

The minimum you need to know about GitHub Actions

Julie — Wed, 14 Oct 2026 05:16:00 +0000

What is GitHub Actions?

Have you heard of GitHub Actions but assumed it was too complicated to learn? I had the same thought — until I used it on a real project (Build and deploy Hugo site with GitHub Actions, Schedule future-dated posts with Github Actions).

Think of GitHub Actions as a robot living on GitHub: you call it, and it does exactly what you've told it to do. More precisely, it's GitHub's built-in automation. You write a workflow, and GitHub runs it for you whenever one of the events you specify happens.

With GitHub Actions, I no longer build my Hugo site by hand: I push a new post, and the robot builds and deploys it.

In this post I'll show you the two sections every workflow file needs, then walk you through a six-line workflow that you can paste into your own repository today.

A real example: my Hugo site

Let me make this concrete with my own case of static site generation. With Hugo, the classic approach was to build the site locally and manually, then push the generated public/ folder to GitHub for deployment. With GitHub Actions, GitHub's servers take over the build. Now I just need to push a new post, and GitHub will build and deploy the site for me.

Even better, GitHub Actions can run on a schedule, so it runs at the time and frequency you choose.

The magic is in the workflow file

So how does it actually work?

The key is to define the workflow file: a .yml or .yaml file under .github/workflows/. It's the set of instructions we hand the "robot" in advance, so it knows what to do when it's triggered.

Note: a workflows/ folder can hold several workflow files.

Two sections are required: on and jobs.

The `on` section: when it runs

The on section specifies which events trigger the workflow. For example, a push to a branch, or a pull_request.

Let's use the Hugo site as our example. Its workflow lists three triggers: push, schedule, and workflow_dispatch.

on:
  push:
    branches:
      - main
  schedule:
    - cron: '26 1 * * *'
  workflow_dispatch:

The push trigger means the workflow runs whenever someone pushes to the main branch.
The schedule trigger runs the workflow on a cron schedule — here, at 01:26 UTC every day. GitHub's cron uses UTC, so convert your local time. I walk through every cron field in this post).
The workflow_dispatch trigger lets you run the workflow manually. Normally a workflow only starts in response to an event, so testing it means making a throwaway commit. workflow_dispatch exists precisely so you don't have to.

Adding workflow_dispatch puts a Run workflow button at the top of the Actions tab. Here's how to use it:

(1) In your repository, click the Actions tab;

(2) In the left sidebar, click the workflow name;

(3) On the right side, click the Run workflow button. The button only exists when the file contains workflow_dispatch. You can pick the branch here.

(4) The new run appears at the top of the list.

Note: pay attention to the indentation before each trigger. I once made the mistake of putting schedule on the same indentation level as the branches under push, that cost me a lot of time debugging.

The `jobs` section: what it does

The jobs section specifies what the workflow does when it runs. In the Hugo example, the jobs build and deploy the site.

Each job needs two keys:

runs-on: the machine the job runs on (ubuntu-latest, windows-latest, macos-latest, …);
steps: the list of individual tasks to run, in order.

The code below shows the build job. The deploy job that follows it is omitted. You can read the full workflow here .

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      HUGO_VERSION: 0.166.0
    steps:
      - name: Install Hugo CLI
        run: wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb && sudo dpkg -i ${{ runner.temp }}/hugo.deb

      - name: Install Dart Sass
        run: sudo snap install dart-sass

      - name: Checkout
        uses: actions/checkout@v4
        with:
          submodules: recursive
          fetch-depth: 0

      - name: Setup Pages
        id: pages
        uses: actions/configure-pages@v4

      - name: Install Node.js dependencies
        run: "[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || true"

      - name: Build with Hugo
        env:
          HUGO_CACHEDIR: ${{ runner.temp }}/hugo_cache
          HUGO_ENV: production
        run: hugo --gc --minify

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: ./public

Read the job top to bottom and you can follow the flow: install Hugo and Dart Sass; check out the repository onto the runner; build the site with Hugo; and pack the public/ folder as a Pages artifact.

Try it yourself

In fact, you've been using this kind of thing for years — an auto-reply rule in your email app runs the moment a message arrives. GitHub Actions is the same idea applied to your code.

GitHub is full of examples, too. Open your first pull request on a project, for instance, and you may receive a welcome message — that's GitHub Actions at work.

How do you write your first GitHub Action?

You don't need a site on GitHub Pages yet. Start small: set up a push-triggered workflow in any repository. Here's a complete, minimal one:

on: push
jobs:
  hello:
    runs-on: ubuntu-latest
    steps:
      - run: echo "hello"

Save it as .github/workflows/hello.yml in your repository. Push, and it runs.

Keep in mind that GitHub Actions runs on a GitHub-hosted runner, so echo "hello" won't display on your local terminal. Where does it go?

The output is captured in the run's log. To view it, open your repository on GitHub and click the Actions tab. Then click the run and then the job (hello in this example).

Expand the step, and you will see hello in the log.

That's it. Now you have a workflow that runs on every push. And that's the whole trick: you write a workflow file, GitHub does the work.

If you want to go further:

Add a schedule: reuse the schedule trigger from the on section so your site rebuilds itself every night, and please remember the cron runs in UTC.
Add a manual trigger: add workflow_dispatch and you get a Run workflow button, so you can test a workflow change without pushing a throwaway commit.
Read a real one: here's the full workflow file for my Hugo site. Now you should be able to follow it.

Have you set up GitHub Actions in your own repository yet? I'd love to hear what you're automating with it.

How to schedule future-dated posts with Github Actions?

Julie — Tue, 06 Oct 2026 12:30:00 +0000

Sometimes you may write several posts in one sitting when you have ideas, but you may not want to publish them all at once. Instead, you’d like to publish them one at a time on future dates.

You can automate this with GitHub Actions. Here’s how.

Step 1: Add a scheduled trigger to the GitHub Actions workflow

First, set the schedule in `hugo.yml`.

Open your Hugo workflow file, usually at .github/workflows/hugo.yml or .github/workflows/hugo.yaml. In the on: section, add a schedule trigger as follows:

on:
   push:
    branches:
      - main

   #add the following two lines
   schedule:
      - cron: '0 1 * * *'

What do the cron fields mean?

The first two fields specify the minute (0-59) and the hour (0-23) of the scheduled time (in UTC), respectively. In the example above, 0 1 specifies 01:00 UTC.

The last three fields specify the day of the month (1-31), the month (1-12), and the day of the week (0-6, where Sunday is 0). An asterisk (*) matches all values in that field. So when the last three fields are * * * , there is no restriction on the day, month, or day of the week, and the workflow runs daily. Together with 0 1, 0 1 * * * means the workflow runs daily at 01:00 UTC.

Then, push the workflow file to GitHub.

git add .github/workflows/hugo.yml
git commit -m"add daily schedule build for future posts"
git push

Note: Scheduled workflows run from the default branch, and GitHub may delay scheduled runs during periods of high load.

Step 2: Set a future date in the post front matter

In the front matter of a new post, set the date field to the time when you want it to be published.

Set the time in the date field slightly earlier than the schedule build time. For example, if the workflow runs at 01:00 UTC, use 00:00 UTC or earlier. This ensures that the post is no longer in the future when Hugo builds the site.

Previewing future posts locally

You can run hugo server to preview your site locally, but future-dated posts will not appear. To include them, run hugo server --buildFuture or hugo server -F.

Note: Do not add --buildFuture to the GitHub Actions build command (hugo); otherwise, future-dated posts will be published immediately.

Can I use the classic deployment approach?

The key to scheduling future posts is that the build must happen after the post's scheduled publication time. With GitHub Actions, the build runs on GitHub's servers, so it can be scheduled. In the classic approach, you build the site locally and then push the public/ folder to GitHub. The build is performed manually.

Therefore, the classic approach cannot schedule builds by itself. You would need to set up a scheduled task on your own machine or another server to run hugo and push the generated files.

I tried to learn GitHub Actions twice: I failed the first time, but AI helped me succeed the second time

Julie — Wed, 30 Sep 2026 01:17:03 +0000

The first time I tried to deploy a static site using GitHub Actions, I gave up halfway through the tutorials. The second time, with the help of an AI agent, I had the site deployed in several hours — and I finally understood how it all worked.

The first time, I gave up

I first encountered GitHub Actions while reading Hugo static site deployment tutorials. Most showed the classic approach: run hugo locally, push the public folder to GitHub, done. A few mentioned GitHub Actions. This approach uses a workflow and saves time. The automatic workflow sounded efficient and I wanted to give it a try.

But the tutorials were too brief; they only included a few commands and the workflow file (hugo.yml). It was hard to follow because some settings were not written clearly enough. I didn't even know where to put these files. Perhaps the authors assumed that readers were already familiar with GitHub Actions and were simply applying it to static site generation. In fact, I had never used GitHub Actions explicitly before. I spent some time trying to figure out what GitHub Actions actually was. This opened up a much broader topic: there are many different kinds of Actions on GitHub. Eventually, I gave up.

I went back to the classic way. It was simpler — build locally, push public , and deploy. It worked, but every time I published a post I had to build and then push the whole public folder. I told myself I would learn GitHub Actions "someday".

The second time, I succeeded

That "someday" came three years later. This time, when I updated my website, I thought, "Why not let an AI agent help me do this and try GitHub Actions again?"

I opened an AI agent. First, I chatted with it to get a general idea of the differences between the two deployment approaches. It explained that the classic approach builds locally (on your machine) and pushes the output, while GitHub Actions builds on GitHub's servers, so you only need to push your new posts. That was enough context to start.

Then I asked it to set everything up for me. Here is the prompt I used:

In this folder, Mysite is the original folder used to generate the static website using Hugo, and then it was connected to GitHub to deploy GitHub Pages. I used hugo to generate the files and push the public folder to GitHub.

Now I want to: 1. Switch the theme. The new theme has been configured in the Mysite_paper folder, so please use this folder. 2. Switch from pushing the public folder to using GitHub Actions.

Don't do it now. First tell me your plan.

The AI came back with two decisions I needed to make:

Where should the Hugo source code live? In the same repository on new branch, or in a separate repository?
How should the theme be tracked in Git? As a submodule or vendored?

Instead of just picking whatever it recommended, I asked it to explain the trade-offs first. Then I chose the "same repository and new branch" option, so that I wouldn't have to switch between repositories later. I chose to track the theme as a Git submodule. With a submodule, the theme is referenced from its own repository, so you can update it easily later. The vendored approach removes the theme's .git directory and commits the files directly. It looks simpler, but you have to update manually.

Once those decisions were made, the AI agent laid out a clear, step-by-step plan and started implementing it. It added the Git submodule, a .gitignore file, and the workflow file to my local project. After that, the AI agent tried to push to GitHub but failed with the error: GitHub is unreachable from the current network .

So I asked the AI to list what I needed to do manually. Four clear steps. I followed them.

Two things went wrong, and both turned out to be instructive.

First, Git Credential Manager kept asking for authentication. I checked my SSH connection — it was fine. I asked the AI why it thought the connection failed. It realized it had tried HTTPS, whereas I usually used SSH. It then gave me the correct SSH-based command, and the push worked.

Second, the first deployment failed with the error:

building succeeded, deploying failed. Branch 'main' is not allowed to deploy to github-pages due to environment protection rules.

I pasted the error message to the AI. It explained that GitHub Pages was still configured to deploy from the master branch, while my repository now uses the main branch. I followed its instructions to change the branch settings, and the next build succeeded.

What made the difference?

So what changed between the first attempt and the second one? It wasn't that GitHub Actions got easier. It was that AI removed the barriers holding me back.

First, the AI handled the setup work. It wrote the workflow file (hugo.yml), configured the Git submodule, generated the .gitignore file. These are the small, tedious tasks that make a beginner feel lost. With them handled, I could focus on understanding what GitHub Actions actually does instead of fighting with config files.

Second, it lowered the mental barrier. In the past, I thought "this is too complex, I need to learn all of this first." With AI by my side, I knew I could start and ask when I got stuck. Although I still didn't know enough, I had the confidence to work on it and get it done.

This flipped my learning order. I used to think that the right sequence was: learn the theory thoroughly, then practice. Now I think it is: do first, learn along the way. AI can be a great one-on-one tutor, explaining things to you and guiding you through the process.

This time, I didn't look for any tutorials to read. Instead, I asked the AI to tell me what to do at each step. When I didn't understand why to do it, I would pause and asked the AI to explain it. In the end, I got GitHub Actions configured and I learned more through practice than by just reading tutorials.

Do I understand it now?

To be honest, I can't write a workflow file from scratch yet. But I understand the big picture: GitHub builds the site on its own servers, so I only push my Markdown posts. I know where the workflow file lives, what each major step does, and where to look when something breaks. That's more than I knew a week ago, and it's enough to maintain this setup and debug simple issues.

The key shift is this: I didn't wait until I "fully understood" to start. I started with a working scaffold or starter template, and I understood it piece by piece as I built on it.

Final thoughts: start first, learn along the way

This experience changed how I think about learning. For practical skills such as deploying a site, configuring a tool, or building an app, the hardest part isn't understanding. It's starting. Every small roadblock (a confusing config line, an authentication error, a branch setting) is a reason to quit. As a beginner, you don't know where to find the solution. AI can now act as a one-on-one tutor, helping you fix these problems and remove the roadblocks.

If there's a tool or skill you've been putting off because "it's too complex to learn," try this: instead of turning to tutorials, open an AI agent, describe what you want to build or learn. Let the AI give you a general idea first, and then help you get a working version. Ask it to explain what you don't understand as you go. In my experience, once you start working on it, you will run into problems, fix them, and learn a lot along the way.

At least, that was my experience with GitHub Actions. I had put it off for three years. This time, I started with a working setup, asked the AI when I got stuck, and filled in the gaps as I went.

You'll learn more in an afternoon of doing than in a week of reading. And you may find that the thing you've been putting off isn't as hard as you expected.

AI Writes Code Now — So What Should We Actually Learn?

Julie — Sat, 12 Sep 2026 02:51:05 +0000

With AI coding, I can build things faster than ever. Yet I've never felt less in control.

Last November, with the launch of GPT 5.1 and Claude Opus 4.5, something changed: AI started producing production-ready code in minutes.

Since then, I've found myself thinking about building more things. In the past, a lot held me back: where should I start? Should I learn more frontend and backend before diving in? Now AI can put together a project in minutes, and I can study the code afterwards.

But at the same time, I feel like I'm losing control over the projects. I'm not writing the code myself, and I have no idea what exactly each line of code does.

If AI writes most of the code, what should we actually learn — and how?

What to Learn

Regaining Control

I used to think I could only truly understand a project if I understood, or even wrote every line of code myself.

Now that AI writes most of the code, we need to change our perspective and see AI coding as a higher level of abstraction. It produces modules and functions. As long as these parts pass tests and behave as expected, we can use them without knowing every implementation detail.

When scripting languages such as JavaScript and Python came out, some programmers argued that these were not "real" programming languages like C or assembly, because they used a higher level of abstraction and did not compile directly to native machine code in the same way. Today, these scripting languages are widely used. We may see AI coding as an even higher level of abstraction.

But abstraction does not mean blind trust. We regain control by managing module boundaries and risks: what each module is responsible for, what goes in and out, how it fails, and what breaks if we change it. Tests and clear interfaces make this practical. We do not need every detail; we need to know where the risks are and how to check them.

This is control at a higher level. The skills behind it are what we turn to next.

The Core of Coding Skills

I used to think that if AI did the coding, my coding skills would be hard to improve without deliberate practice. However, as Pascal CESCATO pointed out in our conversations about AI coding, "(With AI coding,) I feel that I can spend more time thinking about the system instead of spending hours translating my thoughts into syntax."

This leads me to ask what really matters—the core of coding skills. Syntax still matters, but translating ideas into code is no longer the bottleneck. What matters more is the ability to decompose a problem, choose the right abstractions, design clear interfaces, model data, trace control flow, evaluate trade-offs, and verify behavior. These are the skills that let you supervise AI output rather than merely accept it.

When we read AI-generated code, we should treat it as a design to be examined, not just a result to be accepted. Identify the key decisions: where the module boundaries are, why the interfaces look the way they do, how data is modeled, and which dependencies point in which direction. Then ask whether we would have made the same choices—and what trade-offs those choices imply.

We do not need to study every line, but need to understand the structure well enough to test it and improve it. That kind of understanding is best built in real projects.

How to Practice: Through Projects

Some might argue that basics like syntax are the foundation of coding. If you don't even practice and master them until they become muscle memory, how can you master higher-level skills like architecture?

Don't get me wrong—syntax and other basics are very important; we need to master them. But instead of typing the same lines of code over and over to memorize them, we can now learn them by using them in a project. This approach is more effective.

Start with a project you are interested in. Let AI build the first version.

Then read it as a design: map the modules, trace the data, check the interfaces, and ask what trade-offs it makes.

Finally, rewrite the core part yourself—the part where the real design decisions live—so you use the fundamentals without writing boilerplate again and again.

I had a similar experience before the AI era. When I was learning list comprehensions in Python, I typed out the examples, but I didn't use them in my own code. Some time later, I forgot how to use them.

Then, in a Kaggle competition, the dataset had a huge number of columns. How should I select a few to analyze? In a highly upvoted notebook, the author used list comprehensions to select columns and extract the data. Its elegance impressed me. I had learned the syntax, but I did not know I could apply it to the dataset. Following the notebook's example, I tried selecting different columns as I wanted. After that, I finally knew how to use list comprehensions. Learning them in context was far more effective than studying examples.

Final Thoughts

So what should we learn in the age of AI? The same things that have always mattered—just in a different way.

We still need to learn the fundamentals, but we learn them best by using them in real projects.

We still need to understand code, but not every line.

We regain control not by writing every line of code ourselves, but by understanding how the system fits together and why some parts matter more than others.

What are your thoughts on AI coding? I'd love to hear them — feel free to leave a comment below.

Special thanks to @pascal_cescato_692b7a8a20. Our conversations inspired this post.