🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧩 धडा 02 — pipeline ची रचना: घंटा, डेस्क, कारकून

📍 तुम्ही इथे आहात: 12 पैकी धडा 02 · मागे: lesson-01-why-cicd · पुढे: lesson-03-first-pipeline

📦 या ब्रँचमध्ये काय आहे

धडा 01, आणि कोणतीही pipeline file वाचायला लागणारे शब्द — आणि पहिली खरी pipeline, वरपासून खालपर्यंत वाचलेली, अजून न चालवता. खऱ्या files:

.github/workflows/ci.yml — तपासणी डेस्कचा मार्ग: एक trigger, तीन दिशांना पसरणारा एक job, सहा steps (या धड्यात फक्त वाचायचे)
.circleci/config.yml, .gitlab-ci.yml, Jenkinsfile — तोच मार्ग इतर तीन बोलींमध्ये; आज तुम्ही फक्त त्यांचे शब्द उसने घेता

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

शाळेच्या mailroom 📮 मध्ये जा आणि courier ची एक फेरी पाहा. एक घंटा वाजते 🔔 — नवे पाकीट आले. तो म्हणजे trigger: push, pull request, timer, किंवा कोणीतरी बटण दाबणे.

घंटा अनेक डेस्क 🪑 असलेला एक मार्ग सुरू करते. प्रत्येक डेस्कवर एक कारकून छोट्या कामांची यादी क्रमाने करतो: पाकीट उघडणे, पेन्सिल तासणे, उत्तरे तपासणे, कागदावर शिक्का मारणे. मार्ग म्हणजे workflow, प्रत्येक डेस्क एक job, प्रत्येक काम एक step, आणि कारकून म्हणजे runner — प्रत्यक्ष काम करणारी मशीन.

डेस्क वेगवेगळ्या खोल्यांमध्ये आहेत, म्हणून त्यांच्यामध्ये जे काही जायचे ते पाकिटात 📎 जाते (artifact). तासलेल्या पेन्सिलींचा ड्रॉवर 🗄️ फेऱ्यांमध्ये वेळ वाचवतो (cache). काही डेस्कना बॅज 🪪 लागतो (secret). सूचना शेवटी सराव फलकावर किंवा मुख्य फलकावर 📌 लागतात (environments), आणि मुख्य फलकाआधी प्राचार्यांची सही 🛑 येते (approval). चार courier कंपन्या हीच mailroom वापरतात — त्यांच्या फॉर्मवर वेगळे शब्द असतात, आणि आजचा तोच एकमेव अवघड भाग आहे.

🗺️ आकृती

flowchart TB
    bell["🔔 trigger<br/>on push and pull_request"]
    wf["📮 workflow<br/>ci.yml"]
    j1["🪑 job test node 20"]
    j2["🪑 job test node 22"]
    j3["🪑 job test node 24"]
    s["📝 steps in order<br/>checkout → setup-node → cache → prepare → test → upload"]
    r["🧑‍💼 runner<br/>ubuntu-latest, a fresh machine per job"]
    bell -->|"1 rings"| wf
    wf -->|"2 fans out"| j1
    wf -->|"2 fans out"| j2
    wf -->|"2 fans out"| j3
    j2 -->|"3 one after another"| s
    s -->|"4 executed by"| r

❓ काय

Trigger / event = run सुरू करणारी गोष्ट: push, pull request, schedule, हाताने दाबायचे बटण (ship.yml मधले workflow_dispatch).
Workflow = एक file, एक मार्ग (इथे ci.yml, ship.yml, deploy.yml).
Job = स्वतःच्या नव्या runner वरचे कामाचे एकक. एक job दुसऱ्याची needs: करत नाही तोपर्यंत jobs parallel चालतात.
Step = एक command (run:) किंवा एक पुन्हा वापरता येणारी action (uses:). Steps job ची मशीन वाटून घेतात आणि क्रमाने चालतात.
Runner = job चालवणारी मशीन, vendor ची किंवा तुमची स्वतःची.
Artifact 📎 = माणसासाठी किंवा नंतरच्या job साठी run मधून ठेवलेली file (धडा 05). Cache 🗄️ = inputs च्या hash वरून key दिलेला वेग वाढवणारा साठा (धडा 04). Secret 🪪 = encrypted स्वरूपात ठेवलेले मूल्य, logs मध्ये लपवलेले (धडा 06). Environment 📌 = staging सारखे स्वतःचे नियम असलेले नाव दिलेले target; approval 🛑 = त्याच्यापुढचे माणसाचे फाटक (धडा 08).

🧠 चार बोली, एकच शब्दसंग्रह

📮 mailroom मध्ये	GitHub Actions	CircleCI	GitLab CI	Jenkins
संपूर्ण मार्ग	workflow	workflow	pipeline	pipeline
एक डेस्क (स्वतःची मशीन)	job	job	stage + job	stage
डेस्कवरचे एक काम	step	step	script line	step
कारकून (मशीन)	runner	executor	runner	agent

GitLab चे stages क्रमाने चालतात, त्यांचे jobs शेजारी शेजारी; Jenkins चा stage job च्या जवळचा आहे.

🤔 का

इथून पुढे प्रत्येक run page, error message आणि doc हेच शब्द वापरते, आणि चुकीच्या पातळीवरची चूक महाग पडते: step 3 मध्ये लिहिलेली file step 4 मध्ये असते पण पुढच्या job मध्ये नसते, कारण तो job वेगळी मशीन आहे. मशीनसाठी "job" आणि command साठी "step" म्हणा, की धडे 04–07 मधल्या गोंधळात टाकणाऱ्या failures चा एक संपूर्ण वर्ग नाहीसा होतो. हे शब्द पुढच्या mailroom मध्येही चालतात, तिचा logo कोणताही असो — या कोर्सचे चार-tab pipeline page आणि Docker शाळेचा धडा 12 पाहा.

🔧 कसे (या repo मध्ये)

ci.yml वरपासून वाचा. आधी name आणि घंटा — दोन events, filters नाहीत, म्हणून कोणतीही branch ती वाजवते:

name: ✅ ci

on:
  push:
  pull_request:

संपूर्ण workflow साठी दोन settings: permissions: run चा token लहान करते (धडा 06); concurrency: नव्या push ला जुना run रद्द करू देते (धडा 03):

permissions:
  contents: read            # lesson 06: the job's own token gets the least it needs

concurrency:                # a newer push cancels the older run of the same branch
  group: ci-${{ github.ref }}
  cancel-in-progress: true

मग jobs: एकच, test, ज्याला matrix तीन डेस्कमध्ये बदलते (तीन फूटपट्ट्या 📏, धडा 04), प्रत्येक नव्या runner वर, प्रत्येक app/ मध्ये:

jobs:
  test:
    name: test (node ${{ matrix.node }})
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false      # lesson 04: let all three rulers finish, even if one fails
      matrix:
        node: [20, 22, 24]  # three rulers — the same homework checked three ways
    defaults:
      run:
        working-directory: app

शेवटी steps, क्रमाने. uses: प्रकाशित action उसनी घेते; run: shell command चालवते. पहिल्या दोन्ही uses: आहेत:

    steps:
      - name: 📥 checkout
        uses: actions/checkout@v4

      - name: 🟢 node ${{ matrix.node }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}

आणखी चार येतात: cache step (id: cache), if: steps.cache.outputs.cache-hit != 'true' ने राखलेली prepare step (दोन्ही धडा 04), 🧪 test step (धडा 03 ती उद्धृत करतो), आणि if: always() असलेली upload step (धडा 05).

स्वतःची file लिहिण्याआधी YAML चे दोन सापळे:

YAML 1.1 मध्ये on: हा boolean आहे. GitHub तो on key म्हणून वाचतो, पण काही linters आणि libraries (yamllint चा truthy नियम, PyYAML, Ruby चे Psych) त्याचे true करतात. एखादे tool तक्रार करत असेल, तर "on": लिहा.
Indentation आणि quoting अर्थ ठरवतात. Test step run: > वापरते, एक folded block — तीन ओळी एक command बनतात; run: | तीन चालवेल. Outputs strings असतात, म्हणून खरी file cache-hit ची तुलना 'true' शी करते, quotes नसलेल्या true शी नाही. एक जागा जास्त डावीकडे असलेला list item list संपवतो.

🧪 करून पाहा

# 0) fork and clone (you will need this fork from lesson 03 onward)
gh repo fork BaluRaut/learn-cicd-school --clone && cd learn-cicd-school

# 1) read the file and point at each part of the anatomy
cat .github/workflows/ci.yml
grep -nE '^(on|permissions|concurrency|jobs):|runs-on|matrix:|- name:|uses:|run:' .github/workflows/ci.yml
ruby -ryaml -e 'p YAML.load_file(".github/workflows/ci.yml").keys'   # optional, needs ruby: ["name", true, …] — the on: gotcha

# 2) ask GitHub which workflows the fork knows about (enable Actions once in the fork's Actions tab if empty)
gh workflow list

⚠️ नेहमीच्या चुका

"step" म्हणायचे असताना "job" म्हणणे — job ला नवी मशीन मिळते, step एकच मशीन वाटून घेते; step 3 मध्ये बनलेल्या files step 4 मध्ये असतात पण पुढच्या job मध्ये नसतात
steps: ला runs-on: खाली indent करणे (किंवा - name: एक जागा चुकीचा) — YAML अनेक चुकीचे आकार गपचूप स्वीकारते आणि error तुमच्या editor कडून नाही तर GitHub कडून येतो
output ची तुलना quotes नसलेल्या true शी करणे — step outputs strings असतात, म्हणून खरी cache step करते तशीच 'true' शी तुलना करा

⏭️ पुढे

वाचन पुरे. Fork करा, push करा, आणि तपासणी डेस्कला ✅ चा शिक्का मारताना पाहा — मग मुद्दाम ❌ चा शिक्का मारायला लावा, म्हणजे वेळ येण्याआधीच लाल कसे दिसते ते तुम्हाला कळेल.

git checkout lesson-03-first-pipeline

🧩 Lesson 02 — Anatomy of a pipeline: the bell, the desks, the clerks

📍 You are here: Lesson 02 of 12 · Previous: lesson-01-why-cicd · Next: lesson-03-first-pipeline

📦 What's in this branch

Lesson 01, plus the vocabulary you need to read any pipeline file — and the first real one, read top to bottom without running it yet. Real files:

.github/workflows/ci.yml — the checking desk's route: one trigger, one job that fans out three ways, six steps (read only in this lesson)
.circleci/config.yml, .gitlab-ci.yml, Jenkinsfile — the same route in three other dialects; today you only borrow their words

🧒 Explain like I'm 5

Walk into the school mailroom 📮 and watch one round of the courier. A bell rings 🔔 — a new envelope arrived. That is the trigger: a push, a pull request, a timer, or someone pressing a button.

The bell starts a route with several desks 🪑. At each desk a clerk does a short list of tasks in order: open the envelope, sharpen a pencil, check the answers, stamp the sheet. The route is the workflow, each desk a job, each task a step, and the clerk the runner — the machine that actually does the work.

Desks are in different rooms, so anything that must travel between them goes in an envelope 📎 (an artifact). A drawer of sharpened pencils 🗄️ saves time between rounds (a cache). Some desks need a badge 🪪 (a secret). Notices end up on the practice board or the main board 📌 (environments), and the principal's signature 🛑 comes before the main board (an approval). Four courier companies use this same mailroom — with different words on their forms, which is the only hard part of today.

🗺️ Diagram

flowchart TB
    bell["🔔 trigger<br/>on push and pull_request"]
    wf["📮 workflow<br/>ci.yml"]
    j1["🪑 job test node 20"]
    j2["🪑 job test node 22"]
    j3["🪑 job test node 24"]
    s["📝 steps in order<br/>checkout → setup-node → cache → prepare → test → upload"]
    r["🧑‍💼 runner<br/>ubuntu-latest, a fresh machine per job"]
    bell -->|"1 rings"| wf
    wf -->|"2 fans out"| j1
    wf -->|"2 fans out"| j2
    wf -->|"2 fans out"| j3
    j2 -->|"3 one after another"| s
    s -->|"4 executed by"| r

❓ What

Trigger / event = what starts a run: a push, a pull request, a schedule, a manual button (workflow_dispatch in ship.yml).
Workflow = one file, one route (ci.yml, ship.yml, deploy.yml here).
Job = a unit of work on its own fresh runner. Jobs run in parallel unless one needs: another.
Step = one command (run:) or one reusable action (uses:). Steps share the job's machine and run in order.
Runner = the machine that executes a job, vendor-hosted or yours.
Artifact 📎 = a file kept from a run for a human or a later job (lesson 05). Cache 🗄️ = a speed-up keyed by a hash of its inputs (lesson 04). Secret 🪪 = a value stored encrypted, masked in logs (lesson 06). Environment 📌 = a named target such as staging with its own rules; approval 🛑 = a human gate in front of one (lesson 08).

🧠 Four dialects, one vocabulary

📮 in the mailroom	GitHub Actions	CircleCI	GitLab CI	Jenkins
the whole route	workflow	workflow	pipeline	pipeline
one desk (own machine)	job	job	stage + job	stage
one task at a desk	step	step	script line	step
the clerk (the machine)	runner	executor	runner	agent

GitLab's stages run in sequence, their jobs side by side; Jenkins' stage is closer to a job.

🤔 Why

Every run page, error message and doc from here on uses these words, and a mistake at the wrong level is expensive: a file written in step 3 exists in step 4 but not in the next job, because that job is a different machine. Say "job" for a machine and "step" for a command, and a whole class of confusing failures in lessons 04–07 goes away. The words also travel to the next mailroom, whatever its logo — see this course's four-tab pipeline page and the Docker school's lesson 12.

🔧 How (in this repo)

Read ci.yml from the top. First the name and the bell — two events, no filters, so any branch rings it:

name: ✅ ci

on:
  push:
  pull_request:

Two workflow-wide settings: permissions: shrinks the run's token (lesson 06); concurrency: lets a newer push cancel the older run (lesson 03):

permissions:
  contents: read            # lesson 06: the job's own token gets the least it needs

concurrency:                # a newer push cancels the older run of the same branch
  group: ci-${{ github.ref }}
  cancel-in-progress: true

Then the jobs: one, test, that a matrix turns into three desks (three rulers 📏, lesson 04), each on a fresh runner, each inside app/:

jobs:
  test:
    name: test (node ${{ matrix.node }})
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false      # lesson 04: let all three rulers finish, even if one fails
      matrix:
        node: [20, 22, 24]  # three rulers — the same homework checked three ways
    defaults:
      run:
        working-directory: app

Finally the steps, in order. uses: borrows a published action; run: executes a shell command. The first two are both uses::

    steps:
      - name: 📥 checkout
        uses: actions/checkout@v4

      - name: 🟢 node ${{ matrix.node }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}

Four more follow: the cache step (id: cache), the prepare step guarded by if: steps.cache.outputs.cache-hit != 'true' (both lesson 04), the 🧪 test step (lesson 03 quotes it), and the upload step with if: always() (lesson 05).

Two YAML gotchas before you write your own:

on: is a boolean in YAML 1.1. GitHub reads it as the key on, but some linters and libraries (yamllint's truthy rule, PyYAML, Ruby's Psych) turn it into true. If a tool complains, write "on":.
Indentation and quoting decide meaning. The test step uses run: >, a folded block — three lines become one command; run: | would run three. Outputs are strings, so the real file compares cache-hit to 'true', not a bare true. A list item one space too far left ends the list.

🧪 Try it

# 0) fork and clone (you will need this fork from lesson 03 onward)
gh repo fork BaluRaut/learn-cicd-school --clone && cd learn-cicd-school

# 1) read the file and point at each part of the anatomy
cat .github/workflows/ci.yml
grep -nE '^(on|permissions|concurrency|jobs):|runs-on|matrix:|- name:|uses:|run:' .github/workflows/ci.yml
ruby -ryaml -e 'p YAML.load_file(".github/workflows/ci.yml").keys'   # optional, needs ruby: ["name", true, …] — the on: gotcha

# 2) ask GitHub which workflows the fork knows about (enable Actions once in the fork's Actions tab if empty)
gh workflow list

⚠️ Common mistakes

saying "job" when you mean "step" — a job gets a fresh machine, a step shares one; files made in step 3 exist in step 4 but not in the next job
indenting steps: under runs-on: (or a - name: one space off) — YAML accepts many wrong shapes silently and the error arrives from GitHub, not from your editor
comparing an output to a bare true — step outputs are strings, so compare to 'true' exactly as the real cache step does

⏭️ Next

Enough reading. Fork, push, and watch the checking desk stamp ✅ — then make it stamp ❌ on purpose, so you know what red looks like before it matters.

git checkout lesson-03-first-pipeline

← Previouswhy cicd Next →first pipeline

This page is the lesson's README from the lesson-02-pipeline-anatomy branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.