yuval.guide — Guides and hands-on courses on DevOps, cloud, Linux, Python, Kubernetes, networking and AI.

A GitHub Actions workflow is a script that lives in a repository and runs when something happens to that repository. Where it lives: a YAML file in the repository's .github/workflows/ directory, committed like any other file. When it runs: on the events it names — a push, a pull request, a button press, a schedule. …

GitHub Actions runs a workflow when something happens in a repository. An event in the repository, such as a push, starts a run of every workflow that asks for it. The run's job runs on a runner: a fresh virtual machine GitHub creates for it. The runner carries out the job's steps, and the steps act on other places. …

In this part of the pipelines identities you'll create the application repository you'll be using throughout the lab. Here are the calls you'll cover: call 1, you → your repository: you push, over SSH or HTTPS; call 2, job → GitHub: the job checks out the code with GITHUB_TOKEN. It needs only a GitHub account. Create …

In this part you'll make the pipeline push a Docker image to Docker Hub. The call you'll cover: call 3, job → Docker Hub: the job pushes the image with an access token you stored in GitHub. It needs a Docker Hub account. It is the one call in the lab with a credential stored in GitHub, so it is the one a thief could …

In this part you'll have a job ask GitHub for an ID token, and print what it says. The call you'll cover: call 4, job → GitHub: the job asks for an ID token. The token says which repository and branch the job runs for, signed by GitHub. It allows nothing by itself: Part 4 shows it to AWS, which decides what to grant. …

In this part you'll let the pipeline log in to AWS with its ID token. The call you'll cover: call 5, job → AWS STS: the job trades the ID token for AWS credentials. What it adds: AWS is set up once to trust GitHub's tokens for your repository's main branch. No AWS secret is stored in GitHub: each run gets credentials …

In this part you'll let the pipeline deploy to an EKS cluster. The call you'll cover: call 6, job → EKS: the job deploys the image with the AWS credentials from Part 4. What it shows: Two worlds check the job, so it is refused twice before it gets in: IAM decides what the role may do in AWS: read the cluster's address; …

In this part you'll give the cluster a credential of its own, so its pods can pull the private image. The call you'll cover: call 7, cluster → Docker Hub: the node starting a pod pulls the image Part 5 deployed. The caller here is not the job. Part 5's last run was this call's refusal: pull access denied, since the …

In this part you'll have the pipeline tell a Slack channel about each deployment, then clean up the whole lab. The call you'll cover: call 8, job → Slack: the job posts a message after each deployment. The credential is a URL: Slack accepts any message posted to it. It needs a Slack workspace where you may add an app; …

In these labs we connect GitHub Actions to other services: allow GitHub Actions to push images to Docker Hub; allow GitHub Actions to log in to AWS; allow GitHub Actions to deploy to an EKS cluster; allow the EKS cluster to pull images from Docker Hub; allow GitHub Actions to post to Slack. New to GitHub Actions? Start …