What are Github actions?
GitHub Actions is a CI/CD (Continuous Integration/Continuous Deployment) platform integrated into GitHub that allows you to automate workflows directly within your repositories. You can build, test, and deploy your code automatically in response to events like pushes, pull requests, scheduled times, and more.
- 1
Workflows: A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.
- 2
Events: An event is a specific activity in a repository that triggers a workflow run. For example, an activity can originate from GitHub when someone creates a pull request, opens an issue, or pushes a commit to a repository. You can also trigger a workflow to run on a schedule, by posting to a REST API, or manually.
- 3
Jobs: A job is a set of steps in a workflow that is executed on the same runner. Each step is either a shell script that will be executed, or an action that will be run. Steps are executed in order and are dependent on each other. Since each step is executed on the same runner, you can share data from one step to another. For example, you can have a step that builds your application followed by a step that tests the application that was built.
- 4
Actions: An action is a custom application for the GitHub Actions platform that performs a complex but frequently repeated task. Use an action to help reduce the amount of repetitive code that you write in your workflow files. An action can pull your Git repository from GitHub, set up the correct toolchain for your build environment, or set up the authentication to your cloud provider. You can write your own actions, or you can find actions to use in your workflows in the GitHub Marketplace.
- 5
Runners: A runner is a server that runs your workflows when they're triggered. Each runner can run a single job at a time. GitHub provides Ubuntu Linux, Microsoft Windows, and macOS runners to run your workflows. Each workflow run executes in a fresh, newly-provisioned virtual machine.
Scenario Questions
0-2 years experience
- 1Imagine you just joined a team and need to set up a basic workflow that runs our Jest unit tests every time someone opens a pull request against the main branch. Walk me through how you'd write that YAML file and where you'd place it in the repository.
- 2We have a workflow that keeps failing on the build step because it can't find a specific Node version. How would you modify the workflow to ensure it always runs on Node 18, and how do you cache node_modules so the build doesn't take 10 minutes every time?
2-5 years experience
- 1We have a deployment workflow that needs to deploy to staging when a PR is merged, but only deploy to production when a release tag is created. How would you structure your workflow triggers and jobs to handle this safely without duplicating your build steps?
- 2A developer on your team checked in a change to a GitHub Actions workflow, and suddenly the build is failing with a 'Permission Denied' error when trying to push a Docker image to GitHub Packages. How would you go about debugging this, and what role does the GITHUB_TOKEN play here?
5-8 years experience
- 1Our monorepo has 15 different microservices. Right now, any change to a single service triggers the entire CI/CD pipeline, taking 45 minutes and costing us a fortune. How would you redesign our GitHub Actions setup so that we only build and test the services that actually had code changes?
- 2We need to enforce a strict security policy where no third-party GitHub Actions from the marketplace can be used unless they are explicitly audited and approved. How would you configure this at the organization level, and how would you design a custom, reusable action for our internal teams to share?
8+ years experience
- 1We are migrating our entire CI/CD infrastructure from a legacy, self-hosted Jenkins cluster to GitHub Actions. We have hundreds of repositories and strict compliance requirements around data residency and network isolation. How would you architect this migration, manage the runner infrastructure, and ensure consistent compliance across all teams?
- 2At our scale, we are spending tens of thousands of dollars a month on GitHub Actions compute. What strategies, architectural patterns, and monitoring tools would you implement to audit, optimize, and drastically reduce our CI/CD spend without impacting developer velocity?
Follow-up Questions
- How do you secure sensitive credentials like API keys in a GitHub Actions workflow?
- What is the difference between a self-hosted runner and a GitHub-hosted runner, and when would you choose one over the other?
- How do you optimize workflow run times when dealing with heavy dependency installation?