Rokasgrāmata: Git darbplūsmu palaišana tajā pašā skrējējā

GitHub darbplūsmu koordinēšana koplietotajos skrējējus

Vairāku darbplūsmu pārvaldība pakalpojumā GitHub Actions var būt sarežģīta, it īpaši, ja tās ir vajadzīgas, lai tās darbotos vienā un tajā pašā paša mitinātā skrējējā. Gadījumos, kad jums ir atsevišķi YAML faili dažādām darbplūsmām, piemēram, codeql.yml un snyk-zap.yml, nodrošināt, ka tie darbojas vienā un tajā pašā palaidējā no noteiktas grupas, var būt sarežģīti.

Mērķis ir izmantot vienu un to pašu skrējēju abām darbplūsmām, skaidri nenosaucot skrējēju, tādējādi izvairoties no konfliktiem ar citām darbplūsmām. Šajā rokasgrāmatā tiks apskatīti iespējamie risinājumi, kā efektīvi panākt šo sinhronizāciju, vienlaikus saglabājot darbplūsmas atsevišķos YAML failos.

Darbplūsmu koordinēšana ar koplietotajiem skrējējiem

Nodrošinātie skripti pārvalda skrējēju piešķiršanu GitHub darbplūsmām. Bash skripts sākas, pārbaudot, vai skrējēja ID jau ir saglabāts pagaidu failā. Ja nē, tas izmanto curl lai vaicātu GitHub API par pieejamajiem skrējējiem un jq lai parsētu JSON atbildi, atlasot pirmo dīkstāves skrējēju un saglabājot tā ID. Python skripts nodrošina līdzīgu funkcionalitāti, izmantojot requests.get() metode skrējēja informācijas iegūšanai no GitHub API. Pēc tam skripts pārbauda, ​​vai skrējēja ID jau ir saglabāts, izmantojot os.path.exists() un saglabā to, ja nē.

Abi skripti nodrošina, ka pēc skrējēja piešķiršanas tas tiks atkārtoti izmantots nākamajiem darbiem, atsaucoties uz saglabāto skrējēja ID. Python skriptā os.getenv() izgūst vides mainīgos GitHub pilnvarai un repozitorijai, un with open() tiek izmantots, lai droši apstrādātu ar failiem saistītās darbības. Šie skripti palīdz koordinēt vairākas darbplūsmas, nodrošinot, ka tās darbojas vienā un tajā pašā palaidējā, nešifrējot palaidēja nosaukumu, padarot tos elastīgus un efektīvus darbplūsmas izpildes pārvaldībā.

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

Efektīva skrējēju pārvaldība GitHub darbībās

Gadījumos, kad darbplūsmām ir jādarbojas tajā pašā pašmitinātajā palaidējā, galvenais apsvērums ir nodrošināt skrējēja pieejamību un samazināt konfliktus. Izmantojot koplietojamo skrējēja stratēģiju, kā redzams iepriekšējos skriptos, tiek nodrošināts, ka, tiklīdz skrējējs ir piešķirts darbam, nākamie darbi izmanto to pašu skrējēju. Tas var būt īpaši izdevīgi sarežģītos CI/CD konveijeros, kur stāvokļa uzturēšana vai kešatmiņā saglabāto resursu izmantošana ir ļoti svarīga.

Vēl viens aspekts, kas jāņem vērā, ir skrējēju izmantošanas optimizēšana. Dinamiski atlasot un piešķirot skrējējus, pamatojoties uz pieejamību, organizācijas var labāk pārvaldīt savus resursus. Šādu stratēģiju ieviešana ne tikai uzlabo efektivitāti, bet arī samazina laiku, ko darbplūsmas pavada rindā, gaidot pieejamu skrējēju. Šo pieeju var attiecināt uz citiem CI/CD rīkiem un platformām, padarot to par daudzpusīgu risinājumu dažādām automatizācijas vajadzībām.

Secinājums:

Lai nodrošinātu efektivitāti un konsekvenci, ir ļoti svarīgi pārvaldīt GitHub darbplūsmas, lai tās darbotos tajā pašā pašmitinātā skrējējā. Apskatītie Bash un Python skripti nodrošina stabilu risinājumu, dinamiski piešķirot skrējējus un nodrošinot, ka turpmākajos darbos tiek izmantots viens un tas pats skripts. Šī pieeja samazina konfliktus un optimizē resursu izmantošanu, padarot to par efektīvu stratēģiju sarežģītiem CI/CD cauruļvadiem. Ieviešot šīs metodes, organizācijas var racionalizēt darbplūsmas izpildi un samazināt gaidīšanas laiku, galu galā uzlabojot produktivitāti un saglabājot vienmērīgu izstrādes procesu.