गिटहब एक्शन और सीआई/सीडी पाइपलाइनों में प्रॉक्सी: कोड के उदाहरणों के साथ पूर्ण मार्गदर्शिका

```html

GitHub Actions एक शक्तिशाली स्वचालन उपकरण है: यह परीक्षण चलाता है, अनुप्रयोगों को तैनात करता है, डेटा एकत्र करता है और दर्जनों अन्य कार्य करता है। लेकिन जैसे ही वर्कफ़्लो बाहरी संसाधनों - मार्केटप्लेस, विज्ञापन प्लेटफार्मों, विदेशी API - से संपर्क करना शुरू करता है, यह तुरंत भू-प्रतिबंधों और IP सीमाओं का सामना करता है। समाधान एक ही है: पाइपलाइन में सीधे प्रॉक्सी को जोड़ना।

GitHub Actions में प्रॉक्सी की आवश्यकता: वास्तविक परिदृश्य

कई टीमें GitHub Actions का उपयोग केवल कोड तैनात करने के लिए नहीं करती हैं, बल्कि व्यावसायिक कार्यों को स्वचालित करने के लिए भी करती हैं: प्रतिस्पर्धियों की कीमतों की निगरानी, मार्केटप्लेस से डेटा संग्रहण, विज्ञापन खातों की स्वचालित जांच और विभिन्न क्षेत्रों से वेबसाइटों का परीक्षण। इन सभी कार्यों में एक समस्या है - GitHub Actions का रनर Microsoft Azure के IP रेंज से एक निश्चित IP है, और कई सेवाएं इसे ब्लॉक या सीमित कर देती हैं।

यहाँ कुछ विशिष्ट स्थितियाँ हैं जहाँ प्रॉक्सी के बिना काम नहीं चलेगा:

• Wildberries, Ozon, Avito का डेटा संग्रहण - ये प्लेटफार्म लंबे समय से क्लाउड प्रदाताओं के IP रेंज को ब्लैकलिस्ट में डाल चुके हैं। GitHub Actions के रनर से अनुरोध 2-3 प्रयासों में ही ब्लॉक या कैप्चा प्राप्त कर लेगा।
• भू-लक्षित परीक्षण - मार्केटर्स और QA इंजीनियर्स यह जांचते हैं कि वेबसाइट या विज्ञापन मास्को, बर्लिन या न्यूयॉर्क के उपयोगकर्ताओं के लिए कैसे दिखते हैं। बिना प्रॉक्सी के, रनर हमेशा एक क्षेत्र के लिए सामग्री "देखेगा"।
• क्षेत्र द्वारा सीमित API के साथ काम करना - कुछ API (जैसे, Google Ads के क्षेत्रीय संस्करण, Facebook Marketing API कुछ सेटिंग्स के साथ) अनुरोध की भू-स्थान के आधार पर विभिन्न डेटा लौटाते हैं।
• प्रतिस्पर्धियों की निगरानी - कीमतों, प्रचारों और उत्पादों का स्वचालित संग्रह नियमित अनुरोधों की आवश्यकता करता है, जिन्हें डेटा सेंटर के दोहराए जाने वाले IP द्वारा आसानी से पहचान लिया जाता है।
• विज्ञापन जांचों का स्वचालन - आर्बिट्राजर्स और प्रदर्शन मार्केटर्स CI/CD में स्क्रिप्ट के माध्यम से विज्ञापनों की स्थिति, बैलेंस और मेट्रिक्स की स्वचालित जांच करते हैं।
• बाहरी सेवाओं के साथ एकीकरण परीक्षण - कुछ सेवाएं सुरक्षा कारणों से Azure रेंज से अनुरोधों को ब्लॉक करती हैं, और परीक्षण बिना किसी स्पष्टीकरण के गिर जाते हैं।

इन सभी मामलों में, प्रॉक्सी समस्या को नाटकीय रूप से हल करता है: वर्कफ़्लो एक सामान्य उपयोगकर्ता के अनुरोध की तरह दिखने लगता है, न कि Microsoft के क्लाउड सर्वर से।

GitHub Actions नेटवर्क के साथ कैसे काम करता है

प्रॉक्सी सेटअप करने से पहले, GitHub Actions में नेटवर्क आर्किटेक्चर को समझना महत्वपूर्ण है। जब आप मानक ubuntu-latest रनर पर वर्कफ़्लो चलाते हैं, तो कार्य Microsoft Azure के बुनियादी ढांचे में एक वर्चुअल मशीन पर चलता है। ऐसी प्रत्येक मशीन का Azure के रेंज से एक सार्वजनिक IP होता है - और यही IP बाहरी सेवाओं द्वारा देखा जाता है।

GitHub Actions में नेटवर्क की प्रमुख विशेषताएँ:

• प्रत्येक लॉन्च पर IP बदलता है - लेकिन Azure के ज्ञात रेंज के भीतर रहता है, जिन्हें आसानी से पहचाना जा सकता है।
• प्रॉक्सी का अंतर्निहित समर्थन नहीं है - GitHub ट्रैफ़िक को प्रॉक्सी करने के लिए कोई मूल तंत्र प्रदान नहीं करता है।
• पर्यावरण चर वैश्विक रूप से काम करते हैं - यदि आप HTTP_PROXY को नौकरी के स्तर पर सेट करते हैं, तो उस नौकरी के भीतर सभी चरण प्रॉक्सी का उपयोग करेंगे।
• स्व-होस्टेड रनर - एक विकल्प, जिसमें आप अपने सर्वर पर रनर चलाते हैं। इस मामले में, प्रॉक्सी सर्वर के स्तर पर सेट की जाती है, न कि वर्कफ़्लो के।

अधिकांश कार्यों के लिए, प्रॉक्सी को सीधे वर्कफ़्लो फ़ाइल में पर्यावरण चर के माध्यम से सेट करना सबसे अनुकूल दृष्टिकोण है (.github/workflows/your-workflow.yml)। यह एक सार्वभौमिक विधि है, जो अधिकांश उपकरणों के लिए काम करती है: curl, wget, Python requests, Node.js http, Go net/http और अन्य।

CI/CD के लिए किस प्रकार की प्रॉक्सी चुनें

प्रॉक्सी के प्रकार का चयन कार्य पर निर्भर करता है। CI/CD पाइपलाइनों के लिए तीन विकल्प प्रासंगिक हैं, और प्रत्येक की अपनी जगह है:

व्यावहारिक नियम: यदि आपका वर्कफ़्लो Wildberries, Ozon या अन्य एंटी-बॉट सुरक्षा वाले मार्केटप्लेस को स्क्रैप करता है - तो रेसिडेंशियल प्रॉक्सी लें। यदि आप Facebook Ads या TikTok Ads के विज्ञापन खातों का परीक्षण कर रहे हैं - तो मोबाइल प्रॉक्सी लें। सरल एकीकरण परीक्षणों और खुले API के अनुरोधों के लिए डेटा सेंटर प्रॉक्सी पर्याप्त हैं: वे तेज और सस्ते होते हैं।

पर्यावरण चर के माध्यम से प्रॉक्सी सेटअप

GitHub Actions में प्रॉक्सी को जोड़ने का सबसे सार्वभौमिक तरीका मानक पर्यावरण चर HTTP_PROXY, HTTPS_PROXY और NO_PROXY को सेट करना है। अधिकांश कमांड लाइन उपकरण और प्रोग्रामिंग भाषाएँ स्वचालित रूप से इन्हें पकड़ लेती हैं।

प्रॉक्सी के साथ वर्कफ़्लो की बुनियादी संरचना इस प्रकार है:

name: Workflow with Proxy

on:
  schedule:
    - cron: '0 9 * * *'
  workflow_dispatch:

jobs:
  scrape-data:
    runs-on: ubuntu-latest

    env:
      HTTP_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
      HTTPS_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
      NO_PROXY: localhost,127.0.0.1,github.com

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Check current IP (परीक्षण के लिए)
        run: curl -s https://api.ipify.org

      - name: Run main script
        run: python scripts/scraper.py

NO_PROXY ब्लॉक पर ध्यान दें - इसमें उन पते को जोड़ना आवश्यक है, जिनके लिए ट्रैफ़िक को प्रॉक्सी नहीं करना है। कम से कम यह localhost और 127.0.0.1 होना चाहिए। github.com को जोड़ना भी अनुशंसित है, ताकि रिपॉजिटरी के साथ संचालन (चेकआउट, पुश) सीधे हों।

यदि प्रॉक्सी बिना प्रमाणीकरण के है (केवल IP और पोर्ट), तो प्रारूप सरल हो जाता है:

env:
  HTTP_PROXY: http://203.0.113.10:8080
  HTTPS_PROXY: http://203.0.113.10:8080
  NO_PROXY: localhost,127.0.0.1

SOCKS5 प्रॉक्सी के लिए केवल URL में स्कीमा बदलता है:

env:
  HTTP_PROXY: socks5://user:password@proxy-host:1080
  HTTPS_PROXY: socks5://user:password@proxy-host:1080

curl, wget और HTTP अनुरोधों के लिए प्रॉक्सी

यदि पर्यावरण चर नौकरी के स्तर पर सेट किए गए हैं (जैसा कि ऊपर दिखाया गया है), तो curl और wget स्वचालित रूप से उन्हें पकड़ लेंगे। लेकिन कभी-कभी प्रॉक्सी को स्पष्ट रूप से पास करना आवश्यक होता है - उदाहरण के लिए, किसी विशेष चरण के लिए या डिबगिंग के दौरान।

curl में प्रॉक्सी को स्पष्ट रूप से निर्दिष्ट करना:

- name: Fetch data with proxy
  run: |
    curl -x http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }} \
      -s \
      -o output.json \
      https://api.example.com/data

    # प्रॉक्सी के माध्यम से जांच
    curl -x http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }} \
      -s https://api.ipify.org?format=json

wget के लिए:

- name: Download with wget via proxy
  run: |
    wget -e "https_proxy=http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}" \
      -q \
      -O data.html \
      https://target-site.com/page

डिबगिंग के लिए एक उपयोगी चरण - वर्कफ़्लो की शुरुआत में IP पते की जांच जोड़ना। यदि प्रॉक्सी सही तरीके से काम कर रही है, तो आप प्रॉक्सी सर्वर का IP देखेंगे, न कि Azure का:

- name: Verify proxy is active
  run: |
    echo "=== IP without proxy ==="
    curl -s --noproxy '*' https://api.ipify.org || echo "Direct request failed"
    echo ""
    echo "=== IP through proxy ==="
    curl -s https://api.ipify.org

वर्कफ़्लो के भीतर Python स्क्रिप्ट में प्रॉक्सी

Python CI/CD में स्क्रिप्ट के लिए सबसे लोकप्रिय भाषाओं में से एक है। requests पुस्तकालय स्वचालित रूप से पर्यावरण चर HTTP_PROXY और HTTPS_PROXY को पढ़ता है, यदि वे सेट किए गए हैं। लेकिन अधिक लचीले प्रबंधन के लिए, प्रॉक्सी को स्पष्ट रूप से पास करना बेहतर है।

पर्यावरण चर के माध्यम से प्रॉक्सी को स्पष्ट रूप से पास करने वाले Python स्क्रिप्ट का उदाहरण:

import os
import requests

# पर्यावरण चर से प्रॉक्सी डेटा पढ़ें
proxy_host = os.environ.get('PROXY_HOST')
proxy_port = os.environ.get('PROXY_PORT')
proxy_user = os.environ.get('PROXY_USER')
proxy_pass = os.environ.get('PROXY_PASS')

proxies = {
    'http': f'http://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}',
    'https': f'http://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}',
}

# अनुरोध में प्रॉक्सी का उपयोग करें
response = requests.get(
    'https://www.wildberries.ru/catalog/123456/detail.aspx',
    proxies=proxies,
    timeout=30,
    headers={
        'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'
    }
)

print(f"Status: {response.status_code}")
print(f"Content length: {len(response.content)}")

वर्कफ़्लो फ़ाइल में चर को अलग-अलग रहस्यों के रूप में पास करना आवश्यक है (पूर्ण URL के रूप में नहीं), ताकि स्क्रिप्ट उन्हें एकत्र कर सके:

- name: Run Python scraper
  env:
    PROXY_HOST: ${{ secrets.PROXY_HOST }}
    PROXY_PORT: ${{ secrets.PROXY_PORT }}
    PROXY_USER: ${{ secrets.PROXY_USER }}
    PROXY_PASS: ${{ secrets.PROXY_PASS }}
  run: python scripts/scraper.py

Playwright या Selenium के साथ Python में प्रॉक्सी के साथ काम करने के लिए कॉन्फ़िगरेशन थोड़ा अलग है:

# Playwright
from playwright.sync_api import sync_playwright
import os

proxy_url = f"http://{os.environ['PROXY_USER']}:{os.environ['PROXY_PASS']}@{os.environ['PROXY_HOST']}:{os.environ['PROXY_PORT']}"

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy={
            "server": proxy_url
        }
    )
    page = browser.new_page()
    page.goto("https://target-site.com")
    # ... आगे की लॉजिक
    browser.close()

Node.js और npm कार्यों में प्रॉक्सी

Node.js स्वचालित रूप से HTTP_PROXY सिस्टम चर को नहीं पढ़ता है - या तो विशेष पुस्तकालयों का उपयोग करना होता है या प्रॉक्सी को स्पष्ट रूप से सेट करना होता है। सबसे सुविधाजनक विकल्प https-proxy-agent या axios के साथ प्रॉक्सी कॉन्फ़िगरेशन है।

// axios का उपयोग करते हुए
const axios = require('axios');

const proxyConfig = {
  host: process.env.PROXY_HOST,
  port: parseInt(process.env.PROXY_PORT),
  auth: {
    username: process.env.PROXY_USER,
    password: process.env.PROXY_PASS
  }
};

async function fetchData(url) {
  try {
    const response = await axios.get(url, {
      proxy: proxyConfig,
      timeout: 30000,
      headers: {
        'User-Agent': 'Mozilla/5.0 (compatible; MyBot/1.0)'
      }
    });
    return response.data;
  } catch (error) {
    console.error(`Request failed: ${error.message}`);
    throw error;
  }
}

fetchData('https://api.example.com/prices')
  .then(data => console.log(JSON.stringify(data, null, 2)))
  .catch(() => process.exit(1));

npm कमांडों (उदाहरण के लिए, यदि npm कॉर्पोरेट प्रॉक्सी के माध्यम से पैकेज डाउनलोड करने की कोशिश कर रहा है) के लिए कॉन्फ़िगरेशन सरल है:

- name: Configure npm proxy
  run: |
    npm config set proxy http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
    npm config set https-proxy http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}

- name: Install dependencies
  run: npm install

- name: Reset npm proxy (उपयोग के बाद साफ करें)
  run: |
    npm config delete proxy
    npm config delete https-proxy

GitHub Secrets में प्रॉक्सी डेटा का सुरक्षित भंडारण

कभी भी प्रॉक्सी डेटा (होस्ट, पोर्ट, लॉगिन, पासवर्ड) को सीधे वर्कफ़्लो फ़ाइल में स्पष्ट रूप से न रखें। यह सुरक्षा की एक गंभीर गलती है: वर्कफ़्लो फ़ाइलें रिपॉजिटरी में संग्रहीत होती हैं और परियोजना के सभी सदस्यों या यहां तक कि सार्वजनिक रूप से देखी जा सकती हैं।

सही दृष्टिकोण - GitHub Secrets। यहाँ चरण-दर-चरण निर्देश हैं:

1. GitHub पर रिपॉजिटरी खोलें
2. Settings → Secrets and variables → Actions पर जाएँ
3. New repository secret पर क्लिक करें
4. चार रहस्य बनाएं: PROXY_HOST, PROXY_PORT, PROXY_USER, PROXY_PASS
5. वर्कफ़्लो में इनका उपयोग करें ${{ secrets.PROXY_HOST }} सिंटैक्स के माध्यम से

यदि आप घुमाने वाली प्रॉक्सी का उपयोग कर रहे हैं (जब IP प्रत्येक अनुरोध पर या अनुसूची के अनुसार बदलता है), तो अक्सर केवल एक एंडपॉइंट को स्टोर करना पर्याप्त होता है - प्रॉक्सी प्रदाता स्वयं IP पूल का प्रबंधन करता है। इस मामले में, रहस्यों में केवल एक रोटेशन गेटवे का होस्ट और पोर्ट होगा।

प्रॉक्सी का रोटेशन और पाइपलाइन में त्रुटि प्रबंधन

यहां तक कि गुणवत्ता वाली प्रॉक्सी कभी-कभी विफल हो जाती हैं: IP अस्थायी प्रतिबंध में जा सकता है, सत्र टूट सकता है, सर्वर प्रतिक्रिया नहीं दे सकता है। CI/CD पाइपलाइनों के लिए, जो बिना निगरानी के स्वचालित रूप से काम करते हैं, ऐसी स्थितियों के लिए त्रुटि प्रबंधन की योजना बनाना महत्वपूर्ण है।

रणनीति 1: उसी प्रॉक्सी के साथ पुनः प्रयास

import requests
import time
import os

def fetch_with_retry(url, max_retries=3, delay=5):
    proxies = {
        'http': f"http://{os.environ['PROXY_USER']}:{os.environ['PROXY_PASS']}@{os.environ['PROXY_HOST']}:{os.environ['PROXY_PORT']}",
        'https': f"http://{os.environ['PROXY_USER']}:{os.environ['PROXY_PASS']}@{os.environ['PROXY_HOST']}:{os.environ['PROXY_PORT']}",
    }

    for attempt in range(max_retries):
        try:
            response = requests.get(url, proxies=proxies, timeout=30)
            response.raise_for_status()
            return response
        except requests.exceptions.RequestException as e:
            print(f"Attempt {attempt + 1} failed: {e}")
            if attempt < max_retries - 1:
                print(f"Retrying in {delay} seconds...")
                time.sleep(delay)
                delay *= 2  # एक्सपोनेंशियल डिले
    raise Exception(f"All {max_retries} attempts failed for {url}")

रणनीति 2: प्रॉक्सी की सूची के साथ स्विचिंग

यदि आपके पास कई प्रॉक्सी सर्वर हैं, तो आप उन्हें एक रहस्य (कोमा द्वारा) में सूचीबद्ध कर सकते हैं और त्रुटि पर स्विच कर सकते हैं:

import os
import requests
import random

# रहस्य PROXY_LIST में: "host1:port1:user1:pass1,host2:port2:user2:pass2" होता है
proxy_list_raw = os.environ.get('PROXY_LIST', '').split(',')

def parse_proxy(proxy_str):
    parts = proxy_str.strip().split(':')
    if len(parts) == 4:
        host, port, user, password = parts
        return {
            'http': f'http://{user}:{password}@{host}:{port}',
            'https': f'http://{user}:{password}@{host}:{port}',
        }
    return None

proxies = [p for p in [parse_proxy(raw) for raw in proxy_list_raw] if p]

def fetch_with_proxy_rotation(url):
    random.shuffle(proxies)  # यादृच्छिक क्रम
    for proxy in proxies:
        try:
            response = requests.get(url, proxies=proxy, timeout=20)
            if response.status_code == 200:
                return response
        except Exception as e:
            print(f"Proxy failed: {e}, trying next...")
    raise Exception("All proxies exhausted")

रणनीति 3: घुमाने वाले एंडपॉइंट का उपयोग

सबसे सरल विकल्प - एक घुमाने वाले गेटवे के साथ प्रॉक्सी प्रदाता का उपयोग करना। इस मामले में, आप एक पते से कनेक्ट होते हैं, और प्रदाता स्वचालित रूप से पूल से विभिन्न IP प्रदान करता है। कोड में कोई रोटेशन लॉजिक की आवश्यकता नहीं है - केवल एक कनेक्शन स्ट्रिंग पर्याप्त है।

वास्तविक परिदृश्य: डेटा संग्रहण, परीक्षण, मूल्य निगरानी

आइए तीन विशिष्ट परिदृश्यों पर विचार करें, जो उन टीमों में सबसे अधिक सामान्य होते हैं जो GitHub Actions के साथ प्रॉक्सी का उपयोग करती हैं।

परिदृश्य 1: Wildberries पर दैनिक मूल्य निगरानी

मार्केटप्लेस के विक्रेता अक्सर प्रतिस्पर्धियों की कीमतों का स्वचालित संग्रह सेट करते हैं। वर्कफ़्लो एक अनुसूची पर चलता है (उदाहरण के लिए, हर सुबह 7:00 बजे), डेटा एकत्र करता है और इसे Google Sheets में सहेजता है या Telegram पर भेजता है।

name: Daily Price Monitor

on:
  schedule:
    - cron: '0 4 * * *'  # 07:00 MSK (UTC+3)

jobs:
  monitor-prices:
    runs-on: ubuntu-latest

    env:
      HTTP_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
      HTTPS_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
      NO_PROXY: github.com,api.github.com

    steps:
      - uses: actions/checkout@v4

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install dependencies
        run: pip install requests beautifulsoup4 gspread

      - name: Run price scraper
        env:
          GOOGLE_SHEETS_KEY: ${{ secrets.GOOGLE_SHEETS_KEY }}
          TELEGRAM_BOT_TOKEN: ${{ secrets.TELEGRAM_BOT_TOKEN }}
          TELEGRAM_CHAT_ID: ${{ secrets.TELEGRAM_CHAT_ID }}
        run: python scripts/price_monitor.py

      - name: Upload results artifact
        uses: actions/upload-artifact@v4
        with:
          name: price-data-${{ github.run_id }}
          path: output/prices.json

परिदृश्य 2: भू-लक्षित वेबसाइट परीक्षण

मार्केटर्स और QA टीमें यह जांचने के लिए प्रॉक्सी का उपयोग करती हैं कि वेबसाइट या विज्ञापन विभिन्न शहरों के उपयोगकर्ताओं के लिए कैसे दिखते हैं। विशेष रूप से क्षेत्रीय कीमतों, सामग्री और रीडायरेक्ट की जांच के लिए प्रासंगिक है।

name: Geo-targeted Site Tests

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test-moscow:
    runs-on: ubuntu-latest
    name: Test from Moscow
    steps:
      - uses: actions/checkout@v4
      - name: Run geo tests (RU/Moscow proxy)
        env:
          HTTP_PROXY: http://${{ secrets.PROXY_RU_USER }}:${{ secrets.PROXY_RU_PASS }}@${{ secrets.PROXY_RU_HOST }}:${{ secrets.PROXY_RU_PORT }}
          HTTPS_PROXY: http://${{ secrets.PROXY_RU_USER }}:${{ secrets.PROXY_RU_PASS }}@${{ secrets.PROXY_RU_HOST }}:${{ secrets.PROXY_RU_PORT }}
        run: |
          python tests/geo_test.py --region=RU --city=Moscow

  test-germany:
    runs-on: ubuntu-latest
    name: Test from Germany
    steps:
      - uses: actions/checkout@v4
      - name: Run geo tests (DE proxy)
        env:
          HTTP_PROXY: http://${{ secrets.PROXY_DE_USER }}:${{ secrets.PROXY_DE_PASS }}@${{ secrets.PROXY_DE_HOST }}:${{ secrets.PROXY_DE_PORT }}
          HTTPS_PROXY: http://${{ secrets.PROXY_DE_USER }}:${{ secrets.PROXY_DE_PASS }}@${{ secrets.PROXY_DE_HOST }}:${{ secrets.PROXY_DE_PORT }}
        run: |
          python tests/geo_test.py --region=DE

परिदृश्य 3: विज्ञापन खातों की स्वचालित जांच

आर्बिट्राजर्स और प्रदर्शन मार्केटर्स अक्सर Facebook Ads के विज्ञापन खातों, बैलेंस और मेट्रिक्स की स्वचालित जांच के लिए GitHub Actions का उपयोग करते हैं। Azure रेंज से Facebook Marketing API के लिए अनुरोध अतिरिक्त सुरक्षा जांच को ट्रिगर कर सकते हैं - प्रॉक्सी इससे बचने में मदद करता है।

name: Ad Account Health Check

on:
  schedule:
    - cron: '*/30 6-22 * * *'  # 6 से 22 MSK में हर 30 मिनट

jobs:
  check-accounts:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install dependencies
        run: pip install requests

      - name: Check Facebook Ads accounts
        env:
          HTTP_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
          HTTPS_PROXY: http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }}
          FB_ACCESS_TOKEN: ${{ secrets.FB_ACCESS_TOKEN }}
          ACCOUNT_IDS: ${{ secrets.FB_ACCOUNT_IDS }}
          TELEGRAM_BOT_TOKEN: ${{ secrets.TELEGRAM_BOT_TOKEN }}
          TELEGRAM_CHAT_ID: ${{ secrets.TELEGRAM_CHAT_ID }}
        run: python scripts/check_fb_accounts.py

निष्कर्ष

GitHub Actions में प्रॉक्सी सेट करना एक कठिन कार्य नहीं है, यदि सही दृष्टिकोण पता हो। इस मार्गदर्शिका से प्रमुख निष्कर्ष:

• पर्यावरण चर HTTP_PROXY / HTTPS_PROXY - एक सार्वभौमिक तरीका है, जो अधिकांश उपकरणों के लिए कोड में बदलाव किए बिना काम करता है।
• GitHub Secrets - प्रॉक्सी क्रेडेंशियल्स को स्टोर करने के लिए एकमात्र सही स्थान।
• प्रॉक्सी का प्रकार महत्वपूर्ण है: सुरक्षित मार्केटप्लेस के लिए रेसिडेंशियल IP की आवश्यकता होती है, विज्ञापन प्लेटफार्मों के लिए मोबाइल, और सरल API अनुरोधों के लिए डेटा सेंटर प्रॉक्सी उपयुक्त हैं।
• पुनः प्रयास लॉजिक अनिवार्य है उन पाइपलाइनों के लिए, जो बिना निगरानी के अनुसूची के अनुसार काम करती हैं।
• IP की जांच का चरण वर्कफ़्लो की शुरुआत में घंटों की डिबगिंग बचा सकता है।

यदि आपका GitHub Actions वर्कफ़्लो मार्केटप्लेस, विज्ञापन प्लेटफार्मों या किसी भी एंटी-बॉट सुरक्षा वाले सेवाओं के साथ काम करता है, तो हम रेसिडेंशियल प्रॉक्सी का उपयोग करने की सिफारिश करते हैं - इनमें वास्तविक घरेलू उपयोगकर्ताओं के IP होते हैं और ये GitHub सर्वरों के क्लाउड पते की तुलना में बहुत कम अवरोध उत्पन्न करते हैं। Facebook Ads, TikTok या अन्य सामाजिक प्लेटफार्मों से संबंधित कार्यों के लिए, मोबाइल प्रॉक्सी जो ऑपरेटर IP के साथ हैं, सबसे अच्छा विकल्प होगा - ये प्लेटफार्मों की ओर से अधिकतम विश्वास स्तर प्रदान करते हैं।