GitHub Actions

GitHub Actions

1. https://docs.github.com/en/actions
2. https://github.com/academind/github-actions-course-resources/tree/main

Main components

1. Workflows
   1. https://docs.github.com/en/actions/writing-workflows/about-workflows
2. Jobs
   1. Workflows have jobs
   2. Define a Runner (nothing but an execution environment)
3. Steps
   1. Jobs have steps
   2. This is where we define what work needs to be done
      1. shell script or an Action
   3. e.g. Step1: Download the code, Step2: Install dependencies, etc.
4. Events
   1. Triggers Workflows
   2. https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows
5. Actions
   1. Predefined scripts that perform a certain task
   2. You can build your own or use third party Actions
   3. e.g. Checkout Action: https://github.com/actions/checkout
   4. Marketplace: https://github.com/marketplace?type=actions

What do people typically do using GitHub actions?

GitHub Actions is a powerful automation platform that allows developers to automate nearly any task related to their software development lifecycle (SDLC) directly within their GitHub repositories.

The workflows are triggered by events like pushing code, opening a pull request, creating a release, or even on a set schedule.

If a task involves code, GitHub, or any command-line script that can run on a virtual machine, it can likely be automated using GitHub Actions.

People typically use GitHub Actions for two main categories of tasks: CI/CD (DevOps) and Repository/Project Automation.

1. Continuous Integration and Delivery (CI/CD)

This is the most common and foundational use case for GitHub Actions. It automates the process of building, testing, and deploying code.

Use Case	Description	Common Triggers
Continuous Integration (CI)	Automatically runs tests, static code analysis (linting), dependency checks, and builds the application binary/package whenever code is pushed or a pull request is opened.	push, pull_request
Testing	Runs unit, integration, and end-to-end tests across multiple environments (e.g., Node.js 18 on Linux, Node.js 20 on macOS) using Matrix Builds.	pull_request, push
Containerization	Builds Docker images, tags them (often using Semantic Versioning), and pushes the resulting image to a container registry like Docker Hub, AWS ECR, or GitHub Container Registry.	push to main branch, release created
Continuous Deployment (CD)	Automatically deploys the built code or container image to a cloud environment (AWS, Azure, Google Cloud, Kubernetes, etc.) after it passes all checks and is merged to the main branch.	push to main, release created
Package Publishing	Automatically publishes new versions of libraries to public repositories like npm, PyPI, or Maven Central whenever a new GitHub release is created.	release created

2. Repository and Project Automation

This includes automating administrative, maintenance, and communication tasks to keep the project organized and contributors engaged.

Use Case	Description	Common Triggers
Labeling and Triage	Automatically adds labels (e.g., bug, feature, documentation), assigns reviewers, or closes issues based on the issue content, file changes, or a time period (like closing “stale” issues).	issues opened, pull_request opened, schedule (cron)
Documentation & Pages	Automatically builds static site documentation (using tools like Hugo, Jekyll, or MkDocs) and deploys it to GitHub Pages or an external hosting service like Netlify or Vercel.	push to main, push to docs branch
Notifications	Sends automated messages to external services like Slack, Microsoft Teams, or email upon completion or failure of a workflow, deployment status, or when a new pull request needs review.	workflow_run completed, pull_request review requested
Security Scanning	Runs security scans on the code (static analysis) or the dependencies (vulnerability scanning like Trivy) and reports vulnerabilities directly in the pull request.	push, pull_request
Code Formatting	Automatically runs code formatters and linters (like Prettier or Black) and can even commit the formatted changes back to the branch or open a new pull request with the fixes.	push, pull_request