DevOps / Github Interview questions
Explain the execution flow of a GitHub Actions workflow from push to deployment?
When a developer pushes a commit, GitHub evaluates every workflow file under .github/workflows/ against the event, and any workflow whose on conditions match gets triggered as a new run.
sequenceDiagram
participant Dev as Developer
participant GH as GitHub
participant Runner as Actions Runner
participant Reg as GitHub Packages
participant Env as Deploy Target
Dev->>GH: git push (commit)
GH->>GH: Match event against workflow triggers
GH->>Runner: Provision runner, assign build job
Runner->>Runner: Checkout code, run steps
Runner->>Reg: Publish built package/image
Runner-->>GH: Report job status
GH->>Runner: Assign test job (parallel or dependent)
Runner-->>GH: Report test results
GH->>Runner: Assign deploy job (needs: build, test)
Runner->>Env: Deploy artifact
Runner-->>GH: Report deployment status
GH-->>Dev: Update checks on commit/PR
Within a workflow, jobs run in parallel by default unless a needs relationship forces one job to wait for another, such as a deploy job that needs both build and test to succeed first. Artifacts produced by an early job (a compiled binary, a built image reference) can be uploaded and downloaded by a later job so work isn't repeated. The final result, success or failure, is reported back as a status check on the commit and any associated pull request, which is what required status checks use to gate merging.
What determines whether a workflow is triggered by a push event?
A deploy job that lists needs: [build, test] will:
More Related questions...
