पुश करने से पहले स्थानीय स्तर पर GitHub Actions और GitLab CI कैसे चलाएं

आप अपने कंप्यूटर पर GitHub Actions को `act` के साथ चला सकते हैं, और GitLab CI को gitlab-ci-local के साथ चला सकते हैं: दोनों अपनी पाइपलाइन फ़ाइल को पढ़ें और प्रत्येक कार्य को Docker कंटेनर में शुरू करें। Docker इंस्टॉल करें, रनर इंस्टॉल करें, फिर रिपॉजिटरी के फ़ोल्डर से act -j test या gitlab-ci-local test चलाएं। एक असफल कार्य अब आपकी मशीन पर पुश करने और होस्ट किए गए धावक की प्रतीक्षा के बजाय सेकंडों में विफल हो जाता है।

यह मार्गदर्शिका बताती है कि macOS, Windows और Linux पर क्या स्थापित करना है, दोनों धावकों के लिए आदेश, एक नमूना वर्कफ़्लो जिसे आप कॉपी कर सकते हैं, स्थानीय रन की सीमाएं और लोगों द्वारा सबसे पहले की जाने वाली त्रुटियां। वॉकथ्रू हमारे द्वारा बनाए गए Git क्लाइंट GitTree का उपयोग करता है: इसका स्थानीय पाइपलाइन पेज यह जाँचता है कि आपने क्या इंस्टॉल किया है, एक नमूना फ़ाइल लिखता है और आपके लिए सटीक कमांड तैयार करता है। स्थानीय पाइपलाइनें GitTree की निःशुल्क योजना का हिस्सा हैं और इसके लिए किसी होस्टिंग खाते की आवश्यकता नहीं है।

सीआई पाइपलाइन स्थानीय स्तर पर क्यों चलाएं?

वर्कफ़्लो फ़ाइल में प्रत्येक परिवर्तन एक कोड है जिसे आप तब तक परीक्षण नहीं कर सकते जब तक वह चलता न हो। स्थानीय रनर के बिना लूप है: YAML को संपादित करें, कमिट करें, पुश करें, रनर की प्रतीक्षा करें, लॉग पढ़ें, दोहराएं। प्रत्येक दौर में कुछ मिनट लगते हैं और "पुनः प्रयास करें" जैसी कमिटों का एक निशान छोड़ जाता है। एक स्थानीय रन लूप को सेकंड तक छोटा कर देता है और इतिहास को साफ रखता है।

आपको क्या चाहिए: Docker प्लस एक धावक

दोनों धावक एक कंटेनर में हर काम शुरू करते हैं, इसलिए एक Docker इंजन स्थापित होना चाहिए और चलना चाहिए: Docker Desktop, OrbStack या Colima पर macOS, Docker Desktop पर Windows, Docker Engine या Docker Desktop पर Linux। फिर अपनी फ़ाइल के लिए रनर इंस्टॉल करें।

gitlab-ci-local needs Node.js 18 or later when you install it with npm. Check the setup with docker info, act --version and gitlab-ci-local --version: if docker info fails, start the engine before anything else.

अधिनियम के साथ स्थानीय रूप से GitHub Actions चलाएँ

रिपॉजिटरी के रूट फ़ोल्डर से act चलाएँ। पहले कार्यों की सूची बनाएं, फिर जिस पर आप काम कर रहे हैं उसे चलाएं। डिफ़ॉल्ट रूप से act एक push ईवेंट का अनुकरण करता है, इसलिए जो कार्य केवल अन्य ईवेंट पर चलते हैं उन्हें ईवेंट नाम की आवश्यकता होती है।

# list workflows and jobs
act -l

# run one job from one workflow file
act -W .github/workflows/ci.yml -j test

# simulate a pull request instead of a push
act pull_request -j test

# pass a secret the job needs
act -j deploy -s NPM_TOKEN="$NPM_TOKEN"

# Apple silicon: run x86_64 images
act -j test --container-architecture linux/amd64

पहला रन पूछता है कि किस धावक छवि का उपयोग करना है। मध्यम अधिकांश परियोजनाओं के लिए उपयुक्त है; छोटी छवियों में वे उपकरण शामिल नहीं हैं जिनमें होस्ट किए गए धावक शामिल हैं, और पूरी छवि बहुत बड़ी है। यदि कोई चरण "कमांड नहीं मिला" के साथ विफल हो जाता है, तो -P ubuntu-latest=<image> के साथ एक बड़ी छवि चुनें या एक चरण में टूल इंस्टॉल करें।

GitLab CI को स्थानीय रूप से gitlab-ci-local के साथ चलाएँ

वर्तमान फ़ोल्डर से gitlab-ci-local पढ़ता है .gitlab-ci.yml। बिना किसी तर्क के यह पूरी पाइपलाइन चलाता है; एक कार्य को चलाने के लिए इसे एक कार्य नाम दें। --list नौकरियों को चलाए बिना दिखाता है, यह जांचने का एक त्वरित तरीका है कि YAML पार्स करता है।

# list jobs and stages
gitlab-ci-local --list

# run one job
gitlab-ci-local test

# pass a CI/CD variable
gitlab-ci-local test --variable API_URL=http://localhost:8080

आरंभ करने के लिए एक नमूना वर्कफ़्लो

यह GitTree के GitHub Actions नमूने का आकार है: दो कार्य, निर्माण फिर परीक्षण, जो act और GitHub पर समान कार्य करते हैं। आदेशों को अपने आदेशों से बदलें.

name: GitTree local check

on:
  push:
  pull_request:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: npm ci && npm run build

  test:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/checkout@v4
      - name: Test
        run: npm test

स्थानीय रन होस्ट किए गए सीआई से किस प्रकार भिन्न है

• रहस्य और चर GitHub या GitLab पर कॉन्फ़िगर किए गए उपलब्ध नहीं हैं; उन लोगों को पास करें जिनकी नौकरी को आवश्यकता है।
• कंटेनर, वर्चुअल मशीन नहीं: जिन सेवाओं को सिस्टमडी, या पूर्ण वर्चुअल मशीन की आवश्यकता होती है, वे उसी तरह नहीं चलती हैं।
• छवियाँ होस्ट किए गए धावकों से भिन्न हैं; एक गुम उपकरण एक गुम पैकेज है, टूटा हुआ वर्कफ़्लो नहीं।
• घटनाएँ सिम्युलेटेड हैं: act डिफॉल्ट से push; पुन: प्रयोज्य वर्कफ़्लो, शामिल और टेम्पलेट्स का समाधान रनर द्वारा किया जाता है, आपके संपादक द्वारा नहीं।
• पासिंग लोकल रन एक होस्टेड परिणाम नहीं है: यह लूप को छोटा कर देता है; आपके मेज़बान के पास अभी भी अंतिम शब्द है।

सामान्य त्रुटियाँ और सुधार

पुश करने से पहले: संघर्षों की भविष्यवाणी करें, रहस्यों की जाँच करें, पुश का पूर्वावलोकन करें

एक स्थानीय पाइपलाइन रन एक प्रश्न का उत्तर देता है: क्या नौकरियाँ ख़त्म होंगी। तीन अन्य जांचें पकड़ती हैं कि सीआई क्या देर से रिपोर्ट करता है या बिल्कुल नहीं, और उनमें से प्रत्येक कुछ भी भेजे जाने से पहले आपके कंप्यूटर पर चलता है।

1. मर्ज की भविष्यवाणी करें। git merge-tree --write-tree --name-only HEAD origin/main मेमोरी में विलीन हो जाता है और आपके कामकाजी पेड़ को छुए बिना उन फ़ाइलों को सूचीबद्ध करता है जो विरोध कर सकती हैं। GitTree किसी ऐसे विलय से पहले उसी प्रकार की जाँच करता है और चेतावनी देता है जिससे विरोध हो सकता है; देखें गिट मर्ज विवादों को कैसे हल करें।
2. रहस्यों की जांच करें। किसी कमिट या पुश से पहले, GitTree संभावित टोकन, पासवर्ड और निजी कुंजी के लिए स्थानीय रूप से परिवर्तन को स्कैन करता है और यदि कोई मिलता है तो एक संवाद के साथ रुक जाता है। रिमोट तक पहुंचने वाले रहस्य को घुमाना पड़ता है, इसलिए किसी को पकड़ने का सबसे सस्ता क्षण पुश करने से पहले का है। चेतावनी कोई गारंटी नहीं है, इसलिए आप जो भी भेजते हैं उसकी समीक्षा करें।
3. पुश का पूर्वावलोकन करें। शिप पूर्वावलोकन उन कमिटों और फ़ाइलों को सूचीबद्ध करता है जिन्हें पुश भेजेगा और, प्रत्येक वर्कफ़्लो फ़ाइल के लिए यह पढ़ सकता है, चाहे पाइपलाइन चलेगी, चल सकती है या नहीं चलेगी, कारण के साथ।

फिर कार्य को स्थानीय स्तर पर चलाएं और एक बार पुश करें। गुप्त चेतावनी मार्गदर्शिका और जहाज पूर्वावलोकन मार्गदर्शिका दोनों संवादों को विस्तार से कवर करते हैं।

Bitbucket Pipelines और Azure Pipelines के बारे में क्या?

bitbucket-pipelines.yml या azure-pipelines.yml के लिए कोई स्थानीय धावक नहीं है जो act या gitlab-ci-local से मेल खाता हो। एक व्यावहारिक दृष्टिकोण यह है कि अपने निर्माण और परीक्षण आदेशों को स्क्रिप्ट में रखें, उन्हें अपनी होस्ट की गई पाइपलाइन से कॉल करें, और केवल स्थानीय रन के लिए एक छोटी GitHub Actions या GitLab CI फ़ाइल जोड़ें। GitTree उन फ़ाइलों को चिह्नित करता है कोई स्थानीय धावक नहीं और बिल्कुल इसके लिए नमूने पेश करता है।

Next steps: the Run pipelines locally guide documents every button, CI/CD runs covers hosted runs, re-runs and approvals, and the Tools launcher lists GitTree’s other built-in tools.