Overview of GitHub Actions workflows, triggers, and a sample validation job checking for a required file on push and pull request
GitHub Actions is GitHub’s built-in automation platform that runs workflows defined in your repository. Workflows are YAML files that describe when the automation should run (triggers) and what steps to execute (jobs and steps). Typical uses include testing, building, and deploying code whenever something changes in your repo.Workflows are event-driven: GitHub fires events (pushes, pull requests, scheduled timers, manual triggers, and many others), and your workflows respond to those events.
push — run when commits are pushed to branches or tags.
pull_request — run when a pull request is opened, synchronized, or updated.
schedule — run at regular intervals using cron syntax.
workflow_dispatch — expose a manual run button in the Actions UI.
Many repository events (assigned, labeled, opened, etc.) can also trigger workflows.
You can combine triggers so a single workflow runs on multiple events. For recurring runs, the schedule trigger uses cron syntax. For manual runs from the repository UI, enable workflow_dispatch:
This example creates a lightweight workflow that runs on pushes and pull requests targeting the main branch. It performs a simple check: confirm that index.html exists at the repository root. If the file is missing, the job fails.Create a file at .github/workflows/<name>.yml with the following content:
name: Game Quality Check# Trigger on pushes and pull requests targeting mainon: push: branches: [ main ] pull_request: branches: [ main ] # Optionally allow manual runs from the UI workflow_dispatch:jobs: lint-and-test: runs-on: ubuntu-latest steps: # Step 1: Checkout the repository so the runner has access to files - name: Checkout Repository uses: actions/checkout@v4 # Step 2: Simple validation: ensure index.html exists at repo root - name: Verify Core Files run: | if [ -f "index.html" ]; then echo "✔ index.html found. Ready for launch!" else echo "✖ index.html is missing! Game will not load." exit 1 fi
Place this file under .github/workflows/ and commit to the default branch (for example, main). Any push or pull request that targets main will trigger the workflow automatically.
When GitHub Pages is enabled for a repository, GitHub itself runs an internal workflow to build and deploy your site. That same Actions framework is what your custom workflows use — you can see build and deployment jobs, logs, and statuses in the Actions UI.
You can inspect workflow runs, job decomposition, and logs to troubleshoot or validate behavior. For example, the Pages workflow often runs multiple jobs (build, report status, deploy), which you can expand and view details for.
Once your workflow file is committed to main, the Actions tab will show runs for each push and PR targeting that branch. Click a run to view runner provisioning and logs for each step. Typical checkout-related log lines look like:
The shell step that verifies index.html will echo success or print an error and exit with a non-zero code to fail the job:
if [ -f "index.html" ]; then echo "💻 index.html found. Ready for launch!"else echo "❌ index.html is missing! Game will not load." exit 1fi# shell: /usr/bin/bash -e {0}
That’s the basic flow: declare triggers, define jobs and steps, use actions (for checkout, caching, etc.), and run scripts or other action steps to validate, build, test, or deploy your code.
