A workflow defines a single job whose steps compile a binary and then run a test suite against that freshly compiled file. A colleague suggests splitting the compile and test work into two separate jobs to make the run tidier. The author wants to understand the execution consequence before refactoring. Which statement correctly contrasts how steps behave against how separate jobs behave by default?
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- run: ./compile.sh
- run: ./test.sh- ASteps run sequentially on the same runner and share its filesystem, while separate jobs run on independent runners in parallel and do not share a workspace by default. Correct
- BSteps run in parallel and never share state, while separate jobs always run one after another on a single shared runner that keeps the workspace.
- CSteps and separate jobs behave identically, both running sequentially on the same runner and sharing one persistent filesystem across the whole workflow run.
- DSteps run on independent runners that each clean their filesystem, while separate jobs reuse one runner sequentially and carry the workspace from one job to the next.
Why A is correct: Steps execute in order inside one runner and can read files earlier steps produced, whereas jobs default to parallel runners with isolated filesystems, so the test job would not see the compiled binary without extra wiring.
Why B is wrong: Tempting because it sounds orderly, but it inverts the model: steps run sequentially and share state, and separate jobs run in parallel on independent runners by default rather than serially.
Why C is wrong: Tempting because both are units of work, but only steps share a runner and its filesystem; separate jobs get their own runners, so they are not interchangeable in execution behaviour.
Why D is wrong: Tempting because isolation matters, but it swaps the two: it is jobs that get independent runners, and steps that stay on one shared runner, so the described split is reversed.