Proxy di GitHub Actions dan Pipeline CI/CD: Panduan Lengkap dengan Contoh Kode

```html

GitHub Actions adalah alat otomatisasi yang kuat: ia menjalankan pengujian, menerapkan aplikasi, mengumpulkan data, dan melakukan puluhan tugas lainnya. Namun, begitu workflow mulai mengakses sumber daya eksternal — pasar, platform iklan, API luar negeri — ia segera menghadapi pemblokiran geografis dan batasan IP. Solusinya adalah: menghubungkan proxy langsung ke pipeline.

Mengapa menggunakan proxy di GitHub Actions: skenario nyata

Banyak tim menggunakan GitHub Actions tidak hanya untuk menerapkan kode, tetapi juga untuk mengotomatiskan tugas bisnis: memantau harga pesaing, mengumpulkan data dari pasar, memeriksa status akun iklan secara otomatis, dan menguji situs dari berbagai wilayah. Semua tugas ini memiliki satu masalah yang sama — runner GitHub Actions memiliki IP tetap dari rentang Microsoft Azure, dan banyak layanan memblokir atau membatasinya.

Berikut adalah situasi konkret di mana proxy sangat diperlukan:

• Pemrosesan Wildberries, Ozon, Avito — platform ini telah memasukkan rentang IP penyedia cloud ke dalam daftar hitam. Permintaan dari runner GitHub Actions akan diblokir atau mendapatkan captcha setelah 2–3 percobaan.
• Pengujian geotargeting — pemasar dan insinyur QA memeriksa bagaimana tampilan situs atau iklan untuk pengguna dari Moskow, Berlin, atau New York. Tanpa proxy, runner akan selalu "melihat" konten untuk satu wilayah.
• Kerja dengan API yang dibatasi berdasarkan wilayah — beberapa API (misalnya, versi regional Google Ads, Facebook Marketing API dengan pengaturan tertentu) mengembalikan data yang berbeda tergantung pada geolokasi permintaan.
• Pemantauan pesaing — pengumpulan otomatis harga, promosi, dan variasi produk memerlukan permintaan reguler yang mudah terdeteksi berdasarkan IP data center yang berulang.
• Automatisasi pemeriksaan iklan — para arbitrator dan pemasar performa menjalankan pemeriksaan otomatis status iklan, saldo, dan metrik melalui skrip di CI/CD.
• Pengujian integrasi dengan layanan eksternal — beberapa layanan memblokir permintaan dari rentang Azure karena alasan keamanan, dan pengujian hanya gagal tanpa penjelasan.

Dalam semua kasus ini, proxy secara radikal menyelesaikan masalah: workflow mulai terlihat seperti permintaan dari pengguna biasa dari kota yang diinginkan, bukan dari server cloud Microsoft.

Bagaimana GitHub Actions bekerja dengan jaringan

Sebelum mengatur proxy, penting untuk memahami arsitektur jaringan di GitHub Actions. Ketika Anda menjalankan workflow di runner ubuntu-latest standar, tugas dijalankan di mesin virtual dalam infrastruktur Microsoft Azure. Setiap mesin tersebut memiliki IP publik dari rentang Azure — dan IP inilah yang dilihat oleh layanan eksternal.

Fitur utama jaringan di GitHub Actions:

• IP berubah setiap kali dijalankan — tetapi tetap dalam rentang yang dikenal dari Azure, yang mudah terdeteksi.
• Tidak ada dukungan proxy bawaan — GitHub tidak menyediakan mekanisme nativ untuk memproxy lalu lintas.
• Variabel lingkungan bekerja secara global — jika Anda mengatur HTTP_PROXY di tingkat job, semua langkah di dalam job tersebut akan menggunakan proxy.
• Self-hosted runners — alternatif di mana Anda menjalankan runner di server Anda sendiri. Dalam hal ini, proxy diatur di tingkat server, bukan workflow.

Untuk sebagian besar tugas, pendekatan yang optimal adalah mengatur proxy melalui variabel lingkungan langsung di file workflow (.github/workflows/your-workflow.yml). Ini adalah metode universal yang berfungsi untuk sebagian besar alat: curl, wget, Python requests, Node.js http, Go net/http, dan lainnya.

Jenis proxy apa yang harus dipilih untuk CI/CD

Pemilihan jenis proxy tergantung pada tugas. Untuk pipeline CI/CD, ada tiga opsi yang relevan, dan masing-masing memiliki niche sendiri:

Aturan praktis: jika workflow Anda mengambil data dari Wildberries, Ozon, atau pasar lain dengan perlindungan anti-bot — gunakan proxy residensial. Jika Anda menguji akun iklan Facebook Ads atau TikTok Ads — gunakan proxy seluler. Untuk pengujian integrasi sederhana dan permintaan ke API terbuka, cukup gunakan proxy data center: mereka lebih cepat dan lebih murah.

Pengaturan proxy melalui variabel lingkungan

Cara paling universal untuk menghubungkan proxy di GitHub Actions adalah dengan mengatur variabel lingkungan standar HTTP_PROXY, HTTPS_PROXY, dan NO_PROXY. Sebagian besar alat baris perintah dan bahasa pemrograman secara otomatis akan mengambilnya.

Struktur dasar workflow dengan proxy terlihat seperti ini:

name: Workflow dengan 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 (untuk verifikasi)
        run: curl -s https://api.ipify.org

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

Perhatikan blok NO_PROXY — di mana Anda perlu menambahkan alamat yang tidak perlu diproksikan. Setidaknya ini adalah localhost dan 127.0.0.1. Juga disarankan untuk menambahkan github.com, agar operasi dengan repositori (checkout, push) berjalan langsung.

Jika proxy tanpa autentikasi (hanya IP dan port), formatnya disederhanakan:

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

Untuk proxy SOCKS5, hanya skema dalam URL yang berubah:

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

Proxy untuk curl, wget, dan permintaan HTTP di shell

Jika variabel lingkungan diatur di tingkat job (seperti yang ditunjukkan di atas), curl dan wget akan secara otomatis mengambilnya. Namun, terkadang perlu untuk menyampaikan proxy secara eksplisit — misalnya, untuk langkah tertentu atau saat debugging.

Penunjukan eksplisit proxy di curl:

- name: Ambil data dengan 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

    # Verifikasi melalui proxy
    curl -x http://${{ secrets.PROXY_USER }}:${{ secrets.PROXY_PASS }}@${{ secrets.PROXY_HOST }}:${{ secrets.PROXY_PORT }} \
      -s https://api.ipify.org?format=json

Untuk wget:

- name: Unduh dengan wget melalui 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

Langkah berguna untuk debugging — tambahkan pemeriksaan alamat IP di awal workflow. Jika proxy berfungsi dengan benar, Anda akan melihat IP server proxy, bukan Azure:

- name: Verifikasi proxy aktif
  run: |
    echo "=== IP tanpa proxy ==="
    curl -s --noproxy '*' https://api.ipify.org || echo "Permintaan langsung gagal"
    echo ""
    echo "=== IP melalui proxy ==="
    curl -s https://api.ipify.org

Proxy dalam skrip Python di dalam workflow

Python adalah salah satu bahasa paling populer untuk skrip di CI/CD. Pustaka requests secara otomatis membaca variabel lingkungan HTTP_PROXY dan HTTPS_PROXY, jika diatur. Namun, untuk pengelolaan yang lebih fleksibel, lebih baik menyampaikan proxy secara eksplisit.

Contoh skrip Python dengan penyampaian proxy secara eksplisit melalui variabel lingkungan:

import os
import requests

# Membaca data proxy dari variabel lingkungan
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}',
}

# Menggunakan proxy dalam permintaan
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"Panjang konten: {len(response.content)}")

Dalam file workflow, Anda perlu menyampaikan variabel sebagai rahasia terpisah (bukan dalam bentuk URL lengkap), agar skrip dapat mengumpulkannya:

- name: Jalankan pengambil Python
  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

Untuk bekerja dengan Playwright atau Selenium di Python, konfigurasi proxy sedikit berbeda:

# 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")
    # ... logika lebih lanjut
    browser.close()

Proxy di Node.js dan tugas npm

Node.js tidak secara otomatis membaca variabel sistem HTTP_PROXY — Anda perlu menggunakan pustaka khusus atau mengatur proxy secara eksplisit. Opsi yang paling nyaman adalah paket https-proxy-agent atau axios dengan konfigurasi proxy.

// Menggunakan 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(`Permintaan gagal: ${error.message}`);
    throw error;
  }
}

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

Untuk perintah npm (misalnya, jika npm mencoba mengunduh paket melalui proxy perusahaan), konfigurasinya lebih sederhana:

- name: Konfigurasi proxy npm
  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: Instal dependensi
  run: npm install

- name: Reset proxy npm (membersihkan setelah digunakan)
  run: |
    npm config delete proxy
    npm config delete https-proxy

Penyimpanan data proxy yang aman di GitHub Secrets

Jangan pernah menyimpan data proxy (host, port, login, password) langsung di file workflow dalam bentuk terbuka. Ini adalah kesalahan keamanan yang serius: file workflow disimpan di repositori dan dapat dilihat oleh semua anggota proyek atau bahkan publik.

Pendekatan yang benar adalah menggunakan GitHub Secrets. Berikut adalah instruksi langkah demi langkah:

1. Buka repositori di GitHub
2. Pindah ke Settings → Secrets and variables → Actions
3. Klik New repository secret
4. Buat empat rahasia: PROXY_HOST, PROXY_PORT, PROXY_USER, PROXY_PASS
5. Dalam workflow, akses mereka melalui sintaks ${{ secrets.PROXY_HOST }}

Jika Anda menggunakan proxy yang berotasi (ketika IP berubah setiap permintaan atau berdasarkan jadwal), sering kali cukup menyimpan hanya satu endpoint — penyedia proxy mengelola kumpulan IP. Dalam hal ini, hanya ada satu host dan port gateway rotasi di rahasia.

Rotasi proxy dan penanganan kesalahan dalam pipeline

Bahkan proxy berkualitas tinggi kadang-kadang mengalami kegagalan: IP dapat masuk dalam larangan sementara, sesi dapat terputus, server mungkin tidak merespons. Untuk pipeline CI/CD yang berjalan otomatis tanpa pengawasan, penting untuk mempertimbangkan penanganan situasi seperti itu.

Strategi 1: Retry dengan proxy yang sama

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"Percobaan {attempt + 1} gagal: {e}")
            if attempt < max_retries - 1:
                print(f"Mencoba lagi dalam {delay} detik...")
                time.sleep(delay)
                delay *= 2  # Penundaan eksponensial
    raise Exception(f"Semua {max_retries} percobaan gagal untuk {url}")

Strategi 2: Daftar proxy dengan pengalihan

Jika Anda memiliki beberapa server proxy, Anda dapat menyimpan daftar mereka dalam satu rahasia (dipisahkan dengan koma) dan beralih saat terjadi kesalahan:

import os
import requests
import random

# Rahasia PROXY_LIST berisi: "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)  # Urutan acak
    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 gagal: {e}, mencoba yang berikutnya...")
    raise Exception("Semua proxy habis")

Strategi 3: Menggunakan endpoint yang berotasi

Opsi paling sederhana adalah menggunakan penyedia proxy dengan gateway yang berotasi tunggal. Dalam hal ini, Anda terhubung ke satu alamat, dan penyedia secara otomatis memberikan IP yang berbeda dari kumpulan. Tidak ada logika rotasi yang diperlukan dalam kode — cukup satu baris koneksi.

Skenario nyata: pengambilan data, pengujian, pemantauan harga

Mari kita lihat tiga skenario konkret yang paling sering ditemui oleh tim yang menggunakan GitHub Actions dengan proxy.

Skenario 1: Pemantauan harga harian di Wildberries

Penjual di pasar sering mengatur pengumpulan otomatis harga pesaing. Workflow dijadwalkan untuk berjalan (misalnya, setiap pagi pukul 7:00), mengumpulkan data dan menyimpannya di Google Sheets atau mengirimkannya ke Telegram.

name: Pemantauan Harga Harian

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: Siapkan Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Instal dependensi
        run: pip install requests beautifulsoup4 gspread

      - name: Jalankan pengambil harga
        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: Unggah artefak hasil
        uses: actions/upload-artifact@v4
        with:
          name: price-data-${{ github.run_id }}
          path: output/prices.json

Skenario 2: Pengujian situs geotargeting

Pemasar dan tim QA menggunakan proxy untuk memeriksa bagaimana situs atau iklan terlihat bagi pengguna dari berbagai kota. Ini sangat relevan untuk memeriksa harga regional, konten, dan pengalihan.

name: Pengujian Situs Geotargeting

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test-moscow:
    runs-on: ubuntu-latest
    name: Uji dari Moskow
    steps:
      - uses: actions/checkout@v4
      - name: Jalankan uji geotargeting (proxy RU/Moskow)
        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: Uji dari Jerman
    steps:
      - uses: actions/checkout@v4
      - name: Jalankan uji geotargeting (proxy DE)
        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

Skenario 3: Pemeriksaan otomatis akun iklan

Para arbitrator dan pemasar performa sering menggunakan GitHub Actions untuk memeriksa status akun iklan Facebook Ads, saldo, dan metrik secara otomatis. Permintaan ke Facebook Marketing API dari rentang Azure dapat memicu pemeriksaan keamanan tambahan — proxy membantu menghindari ini.

name: Pemeriksaan Kesehatan Akun Iklan

on:
  schedule:
    - cron: '*/30 6-22 * * *'  # Setiap 30 menit dari 6 hingga 22 MSK

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

    steps:
      - uses: actions/checkout@v4

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

      - name: Instal dependensi
        run: pip install requests

      - name: Periksa akun Facebook Ads
        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

Kesimpulan

Mengatur proxy di GitHub Actions bukanlah tugas yang sulit jika Anda tahu pendekatan yang benar. Kesimpulan utama dari panduan ini:

• Variabel lingkungan HTTP_PROXY / HTTPS_PROXY — cara universal yang berfungsi untuk sebagian besar alat tanpa mengubah kode.
• GitHub Secrets — satu-satunya tempat yang benar untuk menyimpan kredensial proxy.
• Jenis proxy itu penting: untuk pengambilan data dari pasar yang dilindungi, diperlukan IP residensial, untuk platform iklan — seluler, untuk permintaan API sederhana, proxy data center sudah cukup.
• Logika retry wajib untuk pipeline yang berjalan tanpa pengawasan berdasarkan jadwal.
• Langkah pemeriksaan IP di awal workflow akan menghemat jam debugging.

Jika workflow GitHub Actions Anda bekerja dengan pasar, platform iklan, atau layanan apa pun dengan perlindungan anti-bot, disarankan untuk menggunakan proxy residensial — mereka memiliki IP nyata dari pengguna rumah dan jauh lebih jarang memicu pemblokiran dibandingkan dengan alamat cloud server GitHub. Untuk tugas yang terkait dengan Facebook Ads, TikTok, atau platform sosial lainnya, pilihan optimal adalah proxy seluler dengan IP operator — mereka memberikan tingkat kepercayaan maksimum dari platform.