GitHub Actions at a glance

GitHub Actions is GitHub's built-in CI/CD and automation platform. You define workflows in YAML files that live in your repository, and GitHub runs them automatically when trigger events occur — like code pushes, pull requests, or issue creation. It is commonly used for tasks such as running vulnerability scans, executing tests, creating releases, or automating routine team notifications.

Several key concepts underpin every workflow:

  • Event — the repository activity that kicks off a workflow (e.g., pushing code or opening an issue).
  • Hosted runners — virtual machines that execute workflow jobs. GitHub maintains hosted runners, or you can configure your own self-hosted runners.
  • Jobs — a set of steps that run together on the same runner. Each step is either a shell command or a ready-made action from the GitHub Marketplace.

When your chosen event fires, GitHub provisions a runner, executes the steps defined in the job, and reports the outcome. The whole process runs unattended.

Want more practice creating your own workflows and getting more familiar with GitHub Actions? Try out the Hello GitHub Actions skill exercise in our skills repository.

Anatomy of a workflow file

In a repository, the Actions tab lists all workflows. To author one, fork a repository, click the Actions tab, then select the green New workflow button in the left column. GitHub displays suggested workflow templates mapped to your repository's detected language and tools. Click Configure on any template to open the editor.

Templates are written in YAML and consist of three core sections you will need to know:

  • Name — a human-readable label that describes what the workflow does.
  • On — the repository events that trigger the workflow.
  • Jobs — the commands and actions that perform the workflow's actual work.

Writing a workflow that labels new issues

Workflows are stored as .yml files in a dedicated .github\workflows directory within the repository. To see GitHub Actions in practice, clone a sample repository, switch to the action-start branch, and navigate to that directory. Use descriptive filenames — such as label-new-issue.yml — so the workflow's purpose is obvious later.

Name: Label New Issues

Next, decide what events should start the workflow. GitHub's trigger events are documented extensively, giving you a choice based on the activity you want to automate. For labeling new issues, set the trigger to fire whenever an issue is opened:

on: 

  issues: 

    types: [opened]

The jobs block is where you delegate the actual work. Each job needs a name and a runner. GitHub supplies hosted runners with up-to-date Ubuntu, Windows, and macOS images; name the job label-issues and assign it to ubuntu-latest to use the newest Ubuntu pool.

Jobs that interact with repository content typically need explicit permission scopes. Adding the permissions keyword inside the job grants all subsequent steps the rights you specify — here, the ability to read repository contents and add a label:

jobs: 

  label-issues:  

    runs-on: ubuntu-latest 

    permissions: 

      issues: write 

      contents: read

The steps that follow dictate what the job actually performs. Two keywords do most of the heavy lifting:

  • uses — imports a prebuilt action from the GitHub Marketplace, saving you from rewriting common routines like checking out code or configuring a Node.js environment.
  • run — executes whatever shell command or script you supply (single-line or multi-line).
    steps: 

      - name: Checkout repository 

        uses: actions/checkout@v6 

      - name: Add triage label 

        env: 

            GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} 

            ISSUE_NUMBER: ${{ github.event.issue.number }} 

            LABEL: "triage" 

        run: gh issue edit "$ISSUE_NUMBER" --add-label "$LABEL"

A step here invokes the GitHub CLI to add a label to the issue that triggered the workflow. Because we rely on the CLI in the run section, we need an access token. GitHub conveniently injects a temporary token as the GITHUB_TOKEN environment variable; assign it to GH_TOKEN in the env block so the CLI can authenticate. Additional environment variables specify which issue to update and which label to add — the label must already exist in the repository for the action to succeed.

With the workflow file authored, commit the changes, push the branch, and merge into main. The workflow is now live.

Putting the workflow to the test

To confirm the workflow works, navigate to the repository in your browser and open the Issues tab. Click the green New issue button, enter a title and description indicating this is a workflow test, then click Create. If everything behaves, the triage label will appear on the issue within moments of its creation.

Monitoring and managing workflows

The Actions tab is the control center for all your workflows. The left column lists each workflow; select Label New Issues to filter the view to its executions. Clicking the top workflow run for the test issue brings up a detail page with a step-by-step log of that execution — useful for debugging why a workflow failed.

The Actions tab also offers management options: Re-run all jobs re-executes a workflow, and the three-dot (…) menu next to a workflow's name includes Disable workflow to pause it without deleting the underlying file. This same view provides access to deployments, runners, metrics, performance, caches, and direct editing of workflow files.

Going further

Issue labeling is only one small use case. GitHub Actions can be configured to publish packages, greet newcomers, build and test code, or run security checks. For more, consult the GitHub Actions documentation and experiment with your own workflows.