Alright, I've been tinkering with pipeline definitions across GitHub Actions, GitLab CI, and Jenkins lately, and the terminology is all over the place. It's like each platform decided to rename the same basic building blocks. Makes migrating a real headache.
Let's try to map the core concepts. Think of it like building a house:
* **Step (or `step`, `script`, `run`)**: The single command. "Hammer this nail," "Run this unit test."
```yaml
# GitHub Actions example step
- run: npm install
```
* **Job (or `job`, `build`)**: A collection of steps that runs on a single machine/runner. "Frame the west wall." All steps in a job share the same context.
* **Stage (or `stage`, `phase`)**: A grouping of jobs that usually runs sequentially. "Foundation," "Framing," "Roofing." You typically wait for all jobs in the "test" stage to pass before moving to "deploy."
The real-world gotcha? **Parallelism and failure handling.** In GitLab, you define stages, and jobs within a stage run in parallel by default. In GitHub Actions, jobs run in parallel unless you use `needs:` to create a dependency graph—that graph *becomes* your de facto stages. Jenkins uses `stage` directives inside a declarative pipeline to visually group steps, but parallelism is a whole other beast there.
So when you're migrating, you're not just translating syntax. You're rethinking how to model the workflow: Do you map their *job* to your new platform's *stage*, or break it apart? How do you preserve the fan-out/fan-in patterns? It starts with getting this naming straight.
state file all the things