---

1️⃣ GitLab CI pipeline ka flow samjhao

Answer:
GitLab CI pipeline me code push ya merge request pe pipeline trigger hoti hai.
Pipeline stages me divide hoti hai jaise build, test, deploy.
Har stage ke andar multiple jobs ho sakti hain jo runners par run hoti hain.
Agar koi job fail hoti hai to pipeline aage nahi badhti.

One-liner:
Pipeline = automated process jo code ko build, test aur deploy karta hai.

---

2️⃣ .gitlab-ci.yml me stages aur jobs ka difference

Answer:
Stages pipeline ke phases hote hain jaise build, test, deploy.
Jobs actual tasks hote hain jo in stages ke andar run karte hain.
Ek stage me multiple jobs parallel run ho sakti hain.

Example:

stages:
  - build
  - test

build_app:
  stage: build
  script: echo "build"

unit_test:
  stage: test
  script: echo "test"

One-liner:
Stage = phase, Job = kaam jo us phase me hota hai.

---

3️⃣ Runner kya hota hai?

Answer:
Runner wo machine ya container hota hai jo pipeline ke jobs execute karta hai.
Runner bina ho to jobs run nahi hoti.
Runner types ho sakte hain: shared runner, project runner, Docker runner.

One-liner:
Runner = worker jo CI jobs chalaata hai.

---

4️⃣ Artifacts aur cache ka use

Answer:
Artifacts build ke output ko next stage me use karne ya download ke liye store karte hain.
Cache dependencies ko save karta hai taaki next pipeline fast chale.

Example:

test:
  script: npm test
  artifacts:
    paths:
      - reports/

cache:
  paths:
    - node_modules/

One-liner:
Artifacts = output share karne ke liye, Cache = speed badhane ke liye.

---

5️⃣ Secrets ko pipeline me kaise use karte ho?

Answer:
Secrets ko GitLab CI variables me store karta hoon.
Unko masked aur protected set karta hoon.
Pipeline me environment variables ki tarah use karta hoon.

Example:

script:
  - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD"

One-liner:
Secrets ko code me nahi, CI variables me secure tareeke se store karta hoon.

---

6️⃣ Manual deployment ka example do

Answer:
Production deploy ko manual rakhta hoon taaki bina approval ke live na ho.
when: manual use karta hoon.

Example:

deploy_prod:
  stage: deploy
  script:
    - ./deploy.sh prod
  when: manual

One-liner:
Production deploy manual rakhta hoon for safety.

---

7️⃣ Branch ke hisaab se job kaise run karoge?

Answer:
Main rules ya only/except ka use karta hoon.
Jaise deploy job sirf main branch par chale.

Example (recommended way):

deploy:
  script: echo "deploy"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

One-liner:
Rules ke through branch based execution control karta hoon.

---

Bonus

8️⃣ rules kya hai?

Answer:
rules decide karta hai job kab run hogi.
Branch, merge request, variables ke base par job trigger kar sakte hain.
Ye only/except ka modern replacement hai.

Example:

job:
  script: echo "run"
  rules:
    - if: '$CI_MERGE_REQUEST_ID'
    - if: '$CI_COMMIT_BRANCH == "main"'

One-liner:
Rules = job kab chalegi ye condition decide karta hai.

---

9️⃣ needs kyu use karte hain?

Answer:
needs se hum job dependencies define karte hain.
Isse jobs parallel chal sakti hain aur pipeline fast ho jaati hai.
Bina needs ke jobs stage by stage strictly wait karti hain.

Example:

build:
  stage: build
  script: echo "build"

test:
  stage: test
  script: echo "test"
  needs: [ build ]

One-liner:
Needs = pipeline ko fast karne ke liye job dependency batata hai.

🎯 30-second interview summary (ready to बोलने के लिए)

GitLab CI me pipeline code push par trigger hoti hai.
Pipeline stages aur jobs me divide hoti hai, jobs runners par execute hoti hain.
Main artifacts se outputs share karta hoon, cache se build fast karta hoon.
Secrets CI variables me secure rakhta hoon.
Production deploy manual rakhta hoon.
Branch based control ke liye rules use karta hoon aur pipeline fast karne ke liye needs ka use karta hoon.