Guida: esecuzione dei flussi di lavoro Git sullo stesso runner

Coordinamento dei flussi di lavoro GitHub su corridori condivisi

Gestire più flussi di lavoro in GitHub Actions può essere complicato, soprattutto quando è necessario che vengano eseguiti sullo stesso runner self-hosted. Negli scenari in cui sono presenti file YAML separati per flussi di lavoro diversi, come codeql.yml e snyk-zap.yml, assicurarsi che vengano eseguiti sullo stesso corridore di un gruppo specifico può essere complicato.

L'obiettivo è utilizzare lo stesso corridore per entrambi i flussi di lavoro senza nominare esplicitamente il corridore, evitando così conflitti con altri flussi di lavoro. Questa guida esplorerà le possibili soluzioni per ottenere questa sincronizzazione in modo efficiente mantenendo i flussi di lavoro in file YAML separati.

Coordinazione dei flussi di lavoro con corridori condivisi

Gli script forniti gestiscono l'assegnazione dei runner per i flussi di lavoro GitHub. Lo script Bash inizia controllando se un ID corridore è già archiviato in un file temporaneo. In caso contrario, utilizza curl per interrogare l'API di GitHub per i corridori disponibili e jq per analizzare la risposta JSON, selezionando il primo corridore inattivo e salvando il suo ID. Lo script Python ottiene funzionalità simili utilizzando il file requests.get() metodo per recuperare le informazioni sui corridori dall'API di GitHub. Lo script controlla quindi se un ID corridore è già memorizzato utilizzando os.path.exists() e lo salva in caso contrario.

Entrambi gli script garantiscono che, una volta assegnato un corridore, verrà riutilizzato per i lavori successivi facendo riferimento all'ID corridore memorizzato. Nello script Python, os.getenv() recupera le variabili di ambiente per il token e il repository GitHub e with open() viene utilizzato per gestire le operazioni sui file in modo sicuro. Questi script aiutano a coordinare più flussi di lavoro, garantendo che vengano eseguiti sullo stesso corridore senza codificare il nome del corridore, rendendoli flessibili ed efficienti nella gestione dell'esecuzione del flusso di lavoro.

# 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}")

Gestione efficiente dei runner nelle azioni GitHub

Negli scenari in cui i flussi di lavoro devono essere eseguiti sullo stesso runner self-hosted, una considerazione chiave è garantire la disponibilità del runner e ridurre al minimo i conflitti. L'utilizzo di una strategia di corridore condiviso, come visto negli script precedenti, garantisce che una volta assegnato un corridore a un lavoro, i lavori successivi utilizzino lo stesso corridore. Ciò può essere particolarmente utile nelle pipeline CI/CD complesse in cui il mantenimento dello stato o l'utilizzo delle risorse memorizzate nella cache è cruciale.

Un altro aspetto da considerare è l'ottimizzazione dell'utilizzo dei corridori. Selezionando e assegnando dinamicamente i corridori in base alla disponibilità, le organizzazioni possono gestire meglio le proprie risorse. L'implementazione di tali strategie non solo migliora l'efficienza, ma riduce anche il tempo che i flussi di lavoro trascorrono in coda, in attesa di un corridore disponibile. Questo approccio può essere esteso ad altri strumenti e piattaforme CI/CD, rendendolo una soluzione versatile per varie esigenze di automazione.

Conclusione:

La gestione dei flussi di lavoro GitHub da eseguire sullo stesso runner self-hosted è fondamentale per l'efficienza e la coerenza. Gli script Bash e Python discussi forniscono una soluzione solida assegnando dinamicamente i corridori e garantendo che i lavori successivi utilizzino lo stesso corridore. Questo approccio riduce al minimo i conflitti e ottimizza l'utilizzo delle risorse, rendendolo una strategia efficace per pipeline CI/CD complesse. Implementando questi metodi, le organizzazioni possono semplificare l'esecuzione del flusso di lavoro e ridurre i tempi di attesa, migliorando in definitiva la produttività e mantenendo un processo di sviluppo regolare.