Konfigurera ett GitHub Actions-arbetsflöde

Slutförd

Här får du lära dig några vanliga konfigurationer i en arbetsflödesfil. Du kommer också att utforska kategorier av händelsetyper, inaktivera och ta bort arbetsflöden och använda specifika versioner av en åtgärd för bästa praxis för säkerhet.

Konfigurera arbetsflöden som ska köras för schemalagda händelser

Som tidigare nämnts kan du konfigurera dina arbetsflöden så att de körs när en specifik aktivitet inträffar på GitHub, när en händelse utanför GitHub inträffar eller vid en schemalagd tidpunkt. Med schedule händelsen kan du utlösa ett arbetsflöde som körs vid specifika UTC-tider med hjälp av POSIX cron-syntax. Den här cron-syntaxen har fem * fält och varje fält representerar en tidsenhet.

Om du till exempel vill köra ett arbetsflöde var 15:e minut schedule skulle händelsen se ut så här:

on:
  schedule:
    - cron:  '*/15 * * * *'

Och om du vill köra ett arbetsflöde varje söndag klockan 03:00 schedule skulle händelsen se ut så här:

on:
  schedule:
    - cron:  '0 3 * * SUN'

Du kan också använda operatorer för att ange ett intervall med värden eller för att ringa in ditt schemalagda arbetsflöde. Det kortaste intervallet du kan köra schemalagda arbetsflöden är en gång var femte minut och de körs på den senaste incheckningen på standard- eller basgrenen.

Konfigurera arbetsflöden som ska köras för manuella händelser

Förutom schemalagda händelser kan du manuellt utlösa ett arbetsflöde med hjälp workflow_dispatch av händelsen. Med den här händelsen kan du köra arbetsflödet med hjälp av GitHub REST API eller genom att välja knappen Kör arbetsflöde på fliken Åtgärder på din lagringsplats på GitHub. Med kan workflow_dispatchdu välja vilken gren du vill att arbetsflödet ska köras på, samt ange valfritt inputs som GitHub ska presentera som formulärelement i användargränssnittet.

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'     
        required: true
        default: 'warning'
      tags:
        description: 'Test scenario tags'  

Förutom workflow_dispatchkan du använda GitHub-API:et för att utlösa en webhook-händelse med namnet repository_dispatch. Den här händelsen gör att du kan utlösa ett arbetsflöde för aktivitet som inträffar utanför GitHub och i princip fungerar som en HTTP-begäran till din lagringsplats och ber GitHub att utlösa ett arbetsflöde från en åtgärd eller webhook. Om du använder den här manuella händelsen måste du göra två saker: skicka en POST begäran till GitHub-slutpunkten /repos/{owner}/{repo}/dispatches med webhook-händelsenamnen i begärandetexten och konfigurera arbetsflödet så att det repository_dispatch använder händelsen.

curl \
  -X POST \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/repos/octocat/hello-world/dispatches \
  -d '{"event_type":"event_type"}'

on:
  repository_dispatch:
    types: [opened, deleted]

Konfigurera arbetsflöden som ska köras för webhook-händelser

Slutligen kan du konfigurera ett arbetsflöde så att det körs när specifika webhook-händelser inträffar på GitHub. Du kan utlösa de flesta webhook-händelser från mer än en aktivitet för en webhook, så om det finns flera aktiviteter för en webhook kan du ange en aktivitetstyp för att utlösa arbetsflödet. Du kan till exempel köra ett arbetsflöde för check_run händelsen, men bara för aktivitetstyperna rerequested eller requested_action .

on:
  check_run:
    types: [rerequested, requested_action]

Använda villkorsstyrda nyckelord

I arbetsflödesfilen kan du komma åt kontextinformation och utvärdera uttryck. Även om uttryck ofta används med det villkorsstyrda if nyckelordet i en arbetsflödesfil för att avgöra om ett steg ska köras eller inte, kan du använda alla kontexter och uttryck som stöds för att skapa en villkorsstyrd. Det är viktigt att veta att när du använder villkor i arbetsflödet måste du använda den specifika syntaxen ${{ <expression> }}, som talar om för GitHub att utvärdera ett uttryck i stället för att behandla det som en sträng.

Ett arbetsflöde som till exempel använder villkoret if för att kontrollera om (grenen github.ref eller taggen ref som utlöste arbetsflödeskörningen) matchar refs/heads/main för att fortsätta med följande steg i arbetsflödet skulle se ut ungefär så här:

name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      ...

Observera att i det här exemplet ${{ }} saknas i syntaxen. Med vissa uttryck, som i fallet med villkorsstyrd if , kan du utelämna uttryckssyntaxen. GitHub utvärderar automatiskt några av dessa vanliga uttryck, men du kan alltid inkludera dem om du glömmer vilka uttryck GitHub utvärderar automatiskt.

Mer information om arbetsflödessyntax och uttryck finns i Arbetsflödessyntax för GitHub Actions.

Inaktivera och ta bort arbetsflöden

När du har lagt till ett arbetsflöde på lagringsplatsen kan du hitta en situation där du tillfälligt vill inaktivera arbetsflödet. Du kan förhindra att ett arbetsflöde utlöses utan att du behöver ta bort filen från lagringsplatsen, antingen på GitHub eller via GitHub REST API. När du vill aktivera arbetsflödet igen kan du enkelt göra det med samma metoder.

Att inaktivera ett arbetsflöde kan vara användbart i vissa situationer, till exempel:

• Ett fel i ett arbetsflöde genererar för många eller felaktiga begäranden som påverkar externa tjänster negativt.
• Du vill tillfälligt pausa ett arbetsflöde som inte är kritiskt och som förbrukar för många minuter för ditt konto.
• Du vill pausa ett arbetsflöde som skickar begäranden till en tjänst som är nere.
• Du arbetar med en förgrening och du behöver inte alla funktioner i vissa arbetsflöden som ingår (till exempel schemalagda arbetsflöden).

Du kan också avbryta en arbetsflödeskörning som pågår i GitHub-användargränssnittet från fliken Åtgärder eller med hjälp av GitHub API-slutpunkten DELETE /repos/{owner}/{repo}/actions/runs/{run_id}. Tänk på att när du avbryter en arbetsflödeskörning avbryter GitHub alla sina jobb och steg inom den körningen.

Använda en organisations mallade arbetsflöde

Om du har ett arbetsflöde som flera team använder i en organisation, i stället för att återskapa samma arbetsflöde för varje lagringsplats, kan du främja konsekvens i hela organisationen med hjälp av en arbetsflödesmall som definieras i organisationens .github lagringsplats. Alla medlemmar i organisationen kan använda ett arbetsflöde för organisationsmallar och alla lagringsplatser i organisationen har åtkomst till dessa mallarbetsflöden.

Du kan hitta dessa arbetsflöden genom att gå till fliken Åtgärder på en lagringsplats i organisationen, välja Nytt arbetsflöde och sedan hitta organisationens arbetsflödesmallavsnitt med titeln "Arbetsflöden som skapats efter organisationsnamn". Organisationen Mona har till exempel ett mallarbetsflöde som visas nedan.

Använda specifika versioner av en åtgärd

När du refererar till åtgärder i arbetsflödet rekommenderar vi att du refererar till en specifik version av den åtgärden i stället för bara själva åtgärden. Genom att referera till en specifik version skyddar du mot oväntade ändringar som skickas till åtgärden som potentiellt kan bryta arbetsflödet. Här är flera sätt att referera till en viss version av en åtgärd:

steps:    
  # Reference a specific commit
  - uses: actions/setup-node@c46424eee26de4078d34105d3de3cc4992202b1e
  # Reference the major version of a release
  - uses: actions/setup-node@v1
  # Reference a minor version of a release
  - uses: actions/setup-node@v1.2
  # Reference a branch
  - uses: actions/setup-node@main

Vissa referenser är säkrare än andra. Om du till exempel refererar till en specifik gren körs den åtgärden av de senaste ändringarna från den grenen, som du kanske eller kanske inte vill ha. Genom att referera till ett specifikt versionsnummer eller checka in SHA-hash är du mer specifik om vilken version av åtgärden du kör. För mer stabilitet och säkerhet rekommenderar vi att du använder inchecknings-SHA för en frisläppt åtgärd i dina arbetsflöden.