Посібник: запуск робочих процесів Git на тому самому Runner

Координація робочих процесів GitHub на спільних раннерах

Керувати декількома робочими процесами в GitHub Actions може бути складно, особливо коли вам потрібно, щоб вони запускалися на тому самому саморозміщеному бігуні. У сценаріях, коли у вас є окремі файли YAML для різних робочих процесів, наприклад codeql.yml і snyk-zap.yml, переконатися, що вони запускаються на тому самому бігуні з певної групи, може бути складно.

Мета полягає в тому, щоб використовувати той самий бігун для обох робочих процесів без явного назви бігуна, щоб уникнути конфліктів з іншими робочими процесами. У цьому посібнику розглядаються можливі рішення для ефективної синхронізації, зберігаючи робочі процеси в окремих файлах YAML.

Координація робочих процесів зі спільними бігунами

Надані сценарії керують призначенням бігунів для робочих процесів GitHub. Сценарій Bash починається з перевірки, чи ідентифікатор бігуна вже зберігається у тимчасовому файлі. Якщо ні, він використовує curl запитувати API GitHub щодо доступних бігунів і jq щоб проаналізувати відповідь JSON, вибравши перший незадіяний бігун і зберігши його ідентифікатор. Сценарій Python досягає подібної функціональності, використовуючи requests.get() для отримання інформації про бігун з API GitHub. Потім сценарій перевіряє, чи вже збережено ідентифікатор бігуна за допомогою os.path.exists() і зберігає його, якщо ні.

Обидва сценарії гарантують, що після призначення бігуна він буде повторно використаний для наступних завдань, посилаючись на збережений ідентифікатор бігуна. У сценарії Python os.getenv() отримує змінні середовища для маркера GitHub і репозиторію, а також with open() використовується для безпечної роботи з файлами. Ці сценарії допомагають координувати кілька робочих процесів, забезпечуючи їх виконання в одному бігуні без жорсткого кодування імені бігуна, що робить їх гнучкими та ефективними в управлінні виконанням робочого процесу.

# A script to manage runner assignment
#!/bin/bash

# Check if a runner is already assigned
RUNNER_ID=$(cat /tmp/runner_id)

if [ -z "$RUNNER_ID" ]; then
  # No runner assigned yet, pick one and save its ID
  RUNNER_ID=$(curl -s -H "Authorization: token $GITHUB_TOKEN" \
               https://api.github.com/repos/$GITHUB_REPOSITORY/actions/runners |
               jq -r '.runners[] | select(.status=="online" and .busy==false) | .id' | head -n 1)
  echo $RUNNER_ID > /tmp/runner_id
fi

echo "Using runner $RUNNER_ID"

# Proceed with the workflow using the assigned runner

import requests
import os

# GitHub API token and repository
GITHUB_TOKEN = os.getenv('GITHUB_TOKEN')
REPO = os.getenv('GITHUB_REPOSITORY')

# Function to get an available runner
def get_runner():
    url = f"https://api.github.com/repos/{REPO}/actions/runners"
    headers = {'Authorization': f'token {GITHUB_TOKEN}'}
    response = requests.get(url, headers=headers)
    runners = response.json()['runners']
    for runner in runners:
        if runner['status'] == 'online' and not runner['busy']:
            return runner['id']
    return None

# Check if a runner is already assigned
if not os.path.exists('/tmp/runner_id'):
    runner_id = get_runner()
    with open('/tmp/runner_id', 'w') as f:
        f.write(str(runner_id))
else:
    with open('/tmp/runner_id', 'r') as f:
        runner_id = f.read()

print(f"Using runner {runner_id}")

Ефективне керування Runner у GitHub Actions

У сценаріях, коли робочі процеси повинні запускатися на тому самому саморозміщеному бігуні, ключовим моментом є забезпечення доступності бігуна та мінімізація конфліктів. Використання спільної стратегії бігуна, як видно з попередніх сценаріїв, гарантує, що після призначення бігуна для завдання наступні завдання використовують той самий бігун. Це може бути особливо корисним у складних конвеєрах CI/CD, де вкрай важливо підтримувати стан або використовувати кешовані ресурси.

Іншим аспектом, який слід розглянути, є оптимізація використання бігуна. Динамічно вибираючи та призначаючи бігунів на основі доступності, організації можуть краще керувати своїми ресурсами. Реалізація таких стратегій не тільки покращує ефективність, але й скорочує час, який робочі процеси проводять у черзі, очікуючи на доступний виконавець. Цей підхід можна поширити на інші інструменти та платформи CI/CD, що робить його універсальним рішенням для різноманітних потреб автоматизації.

Висновок:

Управління робочими процесами GitHub для роботи на тому самому саморозміщеному бігуні має вирішальне значення для ефективності та узгодженості. Обговорювані сценарії Bash і Python забезпечують надійне рішення, динамічно призначаючи бігуни та гарантуючи, що наступні завдання використовують той самий бігун. Цей підхід мінімізує конфлікти та оптимізує використання ресурсів, що робить його ефективною стратегією для складних конвеєрів CI/CD. Впроваджуючи ці методи, організації можуть оптимізувати виконання своїх робочих процесів і скоротити час очікування, зрештою підвищуючи продуктивність і зберігаючи плавний процес розробки.