skip to content

What is GitHub Actions, and where in a repository must a workflow file live to be run?

level: juniorimportance: must knowfreq 72%

answer

  1. Automation living inside the repository host
  2. The path matters and it is a fixed one
  3. A hidden directory, then a subdirectory
  4. Events create runs; runs contain jobs
  5. Files under .github/workflows, one YAML per workflow

basics

~10 s

GitHub Actions is GitHub's built-in automation and CI/CD system. A workflow is a YAML file in the repository's .github/workflows directory that declares the events triggering it and the jobs to run when one occurs.

solid answer

~50 s

GitHub Actions runs automation inside GitHub itself, reacting to things that happen in the repository. The unit is a **workflow**: a YAML file stored in `.github/workflows/` in the repository. Each workflow declares the events that trigger it — a push, a pull request, a schedule, a manual dispatch, a release — and one or more **jobs**; each job runs on a **runner** and is a sequence of steps that either run shell commands or invoke a reusable **action**. When a trigger fires, GitHub creates a **workflow run** whose progress appears in the repository's Actions tab and as checks on the commit or pull request, which is how required status checks connect to Actions. One detail that catches people out: which copy of the file is used depends on the event. Push and pull-request events use the workflow file from the ref involved, while scheduled and manually dispatched workflows come from the default branch — so a schedule added on a feature branch never fires.

code

text · 7 lines
text
my-repo/
├── .github/
│   └── workflows/
│       ├── ci.yml          <- runs on pushes and pull requests
│       ├── nightly.yml     <- scheduled; read from the default branch
│       └── release.yml     <- runs when a release is published
└── src/

go deeper

for a junior

Be able to say what GitHub Actions is in one sentence and give the exact path .github/workflows/. Knowing the words workflow, job, step and runner is what this screener is checking.

for a middle

Explain how an event produces a run, how jobs map onto runners, and which branch's copy of a workflow file GitHub uses for scheduled versus push-triggered runs.

for a senior

Show operational awareness: how job results become named checks that gate merges, why the workflows directory is a sensitive review surface, and how re-running failed jobs fits incident recovery.

for a principal

Frame Actions as a platform decision — automation co-located with the repository and its identity, and what that centralisation implies for governance, cost and blast radius across an organisation.

## What Actions is, as a platform capability GitHub Actions is automation built into the repository host rather than bolted on beside it. Because it lives inside GitHub, it sees repository events directly, writes results back as commit and pull request checks, and gets a scoped credential for the repository automatically. That integration — not the YAML — is what distinguishes it from an external build server pointed at the same repository. The common uses are continuous integration (build and test every push and pull request), continuous delivery (deploy when something merges or a release is published), and general repository automation (labelling, stale-issue sweeps, scheduled maintenance). ## Where the files live Workflows are YAML files in `.github/workflows/` at the root of the repository, with a `.yml` or `.yaml` extension. Files elsewhere — including `.github/` itself or a nested `workflows/` directory deeper in the tree — are not workflows. A repository may hold many workflow files, and each is independent: one may run tests on pull requests while another publishes a release and a third runs nightly. The directory placement is worth knowing precisely because it is also a security boundary: changes to files under `.github/workflows/` are what a reviewer must scrutinise most carefully, since a workflow is code that runs with the repository's credentials. ## The vocabulary - **Event** — something that happened, such as a push, a pull request being opened, a schedule elapsing, or someone triggering a workflow manually. - **Workflow** — the file; it declares which events it responds to and what to do. - **Workflow run** — one execution of a workflow, created when a matching event occurs. - **Job** — a unit of the run that executes on a single runner; jobs run in parallel by default and can be made to wait for each other. - **Step** — one item inside a job: either a shell command or a call to an action. - **Action** — a packaged, reusable step published in a repository, referenced by owner, repository and a version reference. - **Runner** — the machine executing a job, either GitHub-hosted or one you host yourself. ## Which copy of the workflow runs This is the part that surprises people, and it is genuinely a platform question rather than a syntax question. - For **push** and **pull request** events, GitHub uses the workflow file as it exists on the ref involved. So a workflow added on a branch takes effect for pushes to that branch immediately, before it is merged. - For **scheduled** runs and **manual dispatch**, GitHub uses the **default branch**. A schedule defined only on a feature branch never fires, and a manually dispatchable workflow does not appear in the interface until it exists on the default branch. Countless hours are lost to this one. ## How runs surface Each run appears in the Actions tab with per-job logs you can expand step by step, and each job reports back as a check on the commit that triggered it. Those checks are what a repository's required-status-check rules refer to by name, which is how a failing test run blocks a merge. Runs can also be re-run — the whole run or just the failed jobs — which is the everyday recovery from an infrastructure hiccup. ## Answering the question well At junior level, the interviewer wants two things: a one-sentence definition of Actions as GitHub's own CI/CD and automation system, and the exact path `.github/workflows/`. Everything after that is bonus. The strongest cheap addition is the event vocabulary — workflow, run, job, step, runner — followed by the default-branch rule for scheduled and manually dispatched workflows, which shows you have actually debugged "why isn't my workflow running" rather than only read about it.

  • You add a scheduled workflow on a feature branch and nothing ever runs. Why?
    Scheduled workflows are read from the default branch. Until the file is merged there, the schedule simply does not exist as far as GitHub is concerned. The same applies to manually dispatched workflows: the option to run one appears only once the file is on the default branch.
  • How does a GitHub Actions run become a check that can block a merge?
    Each job reports its status back to the commit or pull request as a check with the job's name. A repository rule can then require a check of that name to succeed before merging. The connection is by name, so renaming a job silently breaks the requirement until the rule is updated.
  • What is the difference between a step and an action?
    A step is one item in a job's sequence. It either runs shell commands directly or invokes an action — a packaged, reusable unit published in a repository and referenced by owner, repository and a version reference. Every action is used through a step; not every step uses an action.

saying these in an interview costs you the question

  • Puts workflow files anywhere other than .github/workflows
  • Thinks a scheduled workflow runs from any branch
  • Says Actions is an external CI service integrated with GitHub
  • Confuses a workflow with a single job or step
  • Assumes one repository can only have one workflow file

context

resolving links…