GitHub Actions Explained: Automation That Runs on Every Push

Introduction

Tests only help if they actually run. GitHub Actions is the automation built into GitHub: every time you push code or open a pull request, it can run your Jest tests, your Cypress suite, your build, and even your deployment — automatically, on GitHub's machines, with the results shown right on the pull request.

Workflows: YAML files that describe automation

Automation is defined in a YAML file inside your repository, at .github/workflows/, so it is versioned and reviewed like code:

name: Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm test

on says when it runs (every push and pull request), jobs says what runs (here, one job on Ubuntu), and steps are the commands: check out the code, set up Node 20, install dependencies, run the tests. A red X on a pull request now means "the tests failed" — visible before anyone merges, not discovered in production.

The ecosystem and the one secret rule

Thousands of ready-made actions exist in the Marketplace — setup for every language, deployment to every cloud, linting, security scanning — so most workflows are assembled, not written from scratch. But there is one rule that matters more than any other: never put secrets in a workflow file. API keys and tokens go in the repository's encrypted Secrets settings and are referenced as ${{ secrets.API_KEY }} — they never appear in logs or in the repository history. A leaked key in a public workflow file is compromised the moment it is pushed.

The honest trade

GitHub Actions is free for public repositories and generous for private ones, but minutes are metered — a heavy Cypress suite on every push adds up, which is why teams run fast tests on every push and the slow suite on a schedule or before release. It is also GitHub-specific: if a team ever leaves GitHub, workflows don't transfer. For most teams, that trade is worth it, because the automation lives where the code already lives.

Takeaway

Workflows are YAML in your repository, triggers decide when they run, and results appear on every pull request. Combined with the last two posts' tests, GitHub Actions closes the loop: code is tested automatically, every time, before it ever reaches users.

Comments

Post a Comment

Popular posts from this blog

Swift Explained: Apple's Language for iPhone, Mac, and More

Introduction Swift is Apple's language for its platforms: iPhone, iPad, Mac, Apple Watch, and Apple TV. Introduced in 2014 to replace the older Objective-C, it was designed to be safe, fast, and — unusually for a systems language — genuinely pleasant to read and write. Even if you never ship an app, Swift teaches one idea every developer should understand: optionals. Optionals: saying "this might be missing" Most bugs in app development come from one cause: code assuming a value exists when it does not. Swift makes that assumption impossible to hide. A value that might be missing is wrapped in an Optional, and you must unwrap it before use. var nickname: String? = nil nickname = "Waqas" if let name = nickname { print("Hello, \(name)!") } else { print("No nickname set.") } String? means "a String, or nothing". The if let unwraps it safely: inside the block, name is guaranteed to exist. There is no way to accidentally us...
Read more

Flutter Explained: One Codebase, Every Screen

Introduction Flutter is Google's framework for building apps from a single codebase: write once in Dart, and ship to iOS, Android, web, Windows, macOS, and Linux. It powers apps from Google Pay to the New York Times crossword app. Its core idea is simple and radical: everything on screen is a widget, and the interface is rebuilt from data whenever that data changes. Everything is a widget In Flutter, there are no separate concepts for layout, styling, and controls — everything is a widget, nested inside other widgets like HTML elements, but in code: import 'package:flutter/material.dart'; class Greeting extends StatelessWidget { @override Widget build(BuildContext context) { return Center( child: Text( 'Hello, Sara!', style: TextStyle(fontSize: 24, color: Colors.teal), ), ); } } Center positions its child, Text displays words, TextStyle styles them — each a widget, composed by nesting. Layout widgets (like Row, Column, ...
Read more

Go Explained: Simple Code That Runs Fast

Introduction Go was built at Google for a specific frustration: large programs that were slow to build and hard to read. The answer was a language that is deliberately small — fewer features, but the right ones, done well. If you know one programming language already, Go will feel familiar within an hour. The interesting parts are not the syntax, but two ideas: goroutines and channels. Goroutines: cheap concurrency Most languages make running things at the same time feel heavy — threads, thread pools, and careful setup. A goroutine is Go's lightweight version: you start one by writing go in front of a function call. package main import ( "fmt" "time" ) func say(text string) { for i := 0; i < 3; i++ { fmt.Println(text) time.Sleep(100 * time.Millisecond) } } func main() { go say("hello") say("world") time.Sleep(500 * time.Millisecond) } The go say("hello") line does not wait — it st...
Read more