Skip to content
Interactive AI testing / 05 / Understand GitHub Actions

GitHub Actions Lab

From one code change to a verified website: explore a real workflow, inspect 35 job steps and find the bug that made a build go red.

A real case, a safe teaching environment. The recorded run outcomes below come from fbratten/fbratten.github.io on 17 October 2026. The event-switching exercise is a clearly labelled browser-only prediction. This page never executes GitHub workflows, changes code or contacts an API.

1. What is actually happening in GitHub?

A workflow is a reusable recipe stored as a YAML file in .github/workflows/. A workflow run is one execution of that recipe. The run can contain several jobs, and every job consists of steps executed by a runner.

01 / CodeCommit + pushSave a version of the website and notify GitHub
02 / Workflowpages-browser-check.ymlThe reusable YAML recipe
03 / RunRun IDOne recorded attempt for one commit and event
04 / JobverifyA runner executes a collection of steps
05 / EvidenceTests + receiptsBrowser checks, screenshots and status

The word step is not interchangeable with job. Your example ID 117505847884 identifies one job, not the workflow definition. The enclosing run is 39070132534.

2. Switch between two actual GitHub runs

Both are preserved historical runs of the same site's workflow. The first failed because a mobile layout became wider than the phone viewport. The later run passed after the CSS was repaired, merged and deployed.

Run ID
Job ID
Commit SHA
Trigger
Conclusion
0Successful steps
0Failed steps
0Skipped steps
35Reported steps, including cleanup

Open the source run on GitHub | Read the actual workflow YAML

3. Explore each step and its outcome

These are real recorded step names and results, not invented progress bars. Pick a phase or a step to understand what GitHub did and why a result was green, red or skipped.

This is an interpreted explanation of one recorded GitHub step. See the source run for the log and timestamps.

4. Experiment: change the run trigger

The same workflow can behave differently when started by a push, a pull request or workflow_dispatch (explicit start). Change the event and predict which conditional steps would be eligible to run.

Simulation, not another GitHub run. This exercise interprets explicit workflow if: conditions. It does not predict whether eligible steps would pass, whether deployment would succeed or whether earlier failures would cancel later work.

The condition if: always() allows screenshot-upload steps to run after a failure. if: failure() enables diagnostics only after failure. The exercise marks that dependency rather than inventing a result.

Hypothetical selection receipt






 
5. Debug a real failed job

 
During the first Mutation Gate lab rollout, Playwright opened a 390-pixel mobile viewport and found the page was 456 pixels wide. That violates the test's assertion, so the job correctly failed. No GitHub deployment was proven by that run.

 

  

   390 px phone viewport
456 px page content

  

  

   
Actual test failure, 17 October 2026

   
AssertionError: Mobile overflow on
/labs/mutation-gate/
{"width":456,"viewport":390}

   
Root symptom: the page required sideways scrolling on a phone. The subsequent repair made long technical identifiers wrap, followed by another CI run on the corrected code.

   
Inspect the original failed run

  

 

 
A failed assertion is useful evidence, not a reason to hide the job or mark it green. The developer changes the code, pushes a new commit and runs the checks again.





 
6. A green job is not the entire delivery story

 
For the approved merge commit, a separate GitHub Pages build/deployment run also completed successfully. The verify job then exercised the public website. These are distinct outcomes:

 

  
CI checks
Local static and browser tests check the downloaded code. Green tests prove only their declared scope.
Successful verification run

  
Deployment
A different workflow builds and publishes the website to GitHub Pages. It has its own run ID and outcome.
Pages deployment run

  
Live acceptance
The verification workflow opens the public Pages URL and repeats the browser checks. A checked deployment is not the same as permanent uptime.
Visit the published Mutation Gate lab

 

 
Evidence boundary: the run IDs and results are historical snapshots. This lab does not claim that a new deployment is happening now. An uploaded artifact is not a test verdict; a successful build is not proof that every feature is correct.





 
7. Check your understanding

 

  
1. What does job ID 117505847884 identify?
   
   
   
  

  
2. On a push to main, why is the PR review preview step skipped?
   
   
   
  

  
3. What does a green CI job prove?
   
   
   
  

  
  
Choose all three answers, then check your understanding.

 





 
8. Vocabulary and verified sources

 
Technical expressions link to the existing bilingual From Blueprint to Application glossary. Each link opens the exact entry, with English and plain-language Swedish explanations.

 

 
For deeper testing concepts, continue to Mutation Gate, AI evaluation & CI/CD or return to the Labs directory.