GitHub Pages and GitHub Actions: Publish and Automate

Your repository can do work for you

A repository is more than a folder of files. GitHub can host a website straight from it, and it can run commands automatically whenever something happens, such as a push or a pull request. This lesson covers both.

GitHub Pages: a free website from a repository

GitHub Pages takes the files in a repository (HTML, CSS, JavaScript, images) and serves them as a website, free, with HTTPS, at an address on github.io. There are two kinds:

To publish:

1. Make sure your site's main file is called index.html at the top of the repository.
2. On GitHub, open the repository, then Settings, then Pages.
3. Under Build and deployment, set Source to Deploy from a branch, choose main and / (root), and Save.
4. Wait a minute or two. GitHub shows the live address at the top of the Pages settings.

From then on, every push to main updates the site. Edit, commit, push, and your website is updated. Combine this with the pull request workflow and you have a real, professional process: changes are reviewed first, and merging publishes them.

GitHub Actions: automation that reacts

GitHub Actions runs workflows: small programs that start when an event happens in your repository. Teams use them to:

• Test the code on every push and pull request, so broken code is caught at once.
• Check style and formatting.
• Build and deploy a website or app when main changes.
• Do chores, like labelling issues or sending a message.

This is called CI/CD (continuous integration and continuous delivery): checking and shipping your work automatically, all the time. It is why companies can release many times a day.

Anatomy of a workflow

A workflow is a YAML file in a special folder: .github/workflows/. (YAML is a simple format of keys and values, where indentation matters: use spaces, never tabs.) Here is a small, complete one:

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Get the code
        uses: actions/checkout@v4

      - name: Say hello
        run: echo "The workflow is running"

      - name: List the files
        run: ls

Read it from the top:

Almost every workflow starts the same way: check out the code, then run your tests or build commands. A real Python project might add - run: pip install -r requirements.txt and - run: pytest. A website might build and deploy.

What you see on GitHub

After you push a workflow:

• The Actions tab lists every run, with a green tick (success) or red cross (failure).
• Click a run, then a job, to read the logs: exactly what each step printed. When something fails, the log tells you why. Reading logs is a core skill.
• On a pull request, the checks appear at the bottom, and a failing check can block the merge.

You can even show the status in your README with a badge, a small image that shows "passing" or "failing".

Secrets in Actions

Sometimes a workflow needs a password or key, for example to deploy. Never write it in the YAML file, because that is in your repository (lesson 9). Instead, store it in Settings, then Secrets and variables, then Actions, and use it in the workflow as ${{ secrets.MY_KEY }}. GitHub keeps the value hidden, even in the logs.

Try it

First, add a workflow to a repository. Create the file in the right folder, with the right content, and commit it.

Now write a workflow for a Python project. This is the shape of what many real repositories have.