Administrer handlinger og arbejdsprocesser
Her kan du udforske de forskellige værktøjer og strategier, der er tilgængelige for dig i GitHub Enterprise Cloud og GitHub Enterprise Server, for at dele GitHub-handlinger og -arbejdsprocesser og administrere brugen af dem i din virksomhed.
Indholdet er struktureret omkring det niveau, hvorpå de viste værktøjer er tilgængelige: virksomhedsniveau eller organisationsniveau.
På virksomhedsniveau
Konfigurer en politik for brug af GitHub-handlinger
GitHub Actions-arbejdsprocesser indeholder ofte handlinger, som er sæt af separate kommandoer, der skal udføres i arbejdsprocessen. Når du opretter en arbejdsproces, kan du oprette dine egne handlinger, der skal bruges, eller referere til offentlige communityhandlinger, der er tilgængelige fra GitHub Marketplace. Derfor er det vigtigt at konfigurere en brugspolitik for arbejdsprocesser og handlinger i din virksomhed for at forhindre brugere i at bruge skadelige handlinger fra tredjepart.
Du har flere muligheder i Enterprise Cloud for at konfigurere en politik samt i Enterprise Server, hvis GitHub Connect er aktiveret i dine virksomhedsindstillinger.
Hvis du vil konfigurere en Politik for brug af GitHub-handlinger for din virksomhed, skal du gå til din virksomhedskonto og derefter Politikker > Handlinger i margenteksten. Følgende indstillinger vises.
Rullelisten øverst med navnet Aktivér for alle organisationer giver dig mulighed for at bestemme, hvilke organisationer i din virksomhed der kan bruge GitHub-handlinger (dem alle, nogle af dem eller ingen af dem), mens de tre indstillinger nedenfor giver dig mulighed for at definere begrænsningsniveauet for GitHub-handlinger i disse organisationer.
Hvis du kun vil aktivere bestemte handlinger, der skal bruges i din virksomhed, skal du vælge Tillad virksomhed og vælge ikke-virksomhed, handlinger og arbejdsprocesser, der kan genbruges,og vælge den indstilling, der svarer til din use case.
Synkroniser offentlige handlinger manuelt for Enterprise Server
De fleste officielle GitHub-oprettede handlinger leveres automatisk sammen med Enterprise Server, og de registreres på et tidspunkt fra GitHub Marketplace. De omfatter actions/checkout, actions/upload-artifact, actions/download-artifact, actions/labelerog forskellige actions/setup- handlinger. Hvis du vil hente alle de officielle handlinger, der er inkluderet i din virksomhedsforekomst, skal du gå til handlingsorganisationen for din forekomst: https://HOSTNAME/actions.
Som nævnt i afsnittet Konfigurer en GitHub-handlingsanvendelsespolitik er det muligt at konfigurere Enterprise Server til automatisk at få adgang til de offentlige handlinger, der er tilgængelige på GitHub Marketplace, og konfigurere en brugspolitik for dem. Men hvis du vil have strengere kontrol over de offentlige handlinger, der skal gøres tilgængelige i din virksomhed, kan du manuelt downloade og synkronisere handlinger i din virksomhedsforekomst ved hjælp af værktøjet actions-sync.
På organisationsniveau
Dokumentér virksomhedsstandarder
Oprettelse af en Arbejdsproces for GitHub-handlinger omfatter ofte skrivning af flere filer og oprettelse af flere lagre for at angive arbejdsprocessen i sig selv. Oprettelse omfatter også de handlinger, objektbeholdere og/eller løbere, der skal bruges i arbejdsprocessen. Afhængigt af antallet af brugere i din Enterprise Cloud- eller Enterprise Server-forekomst kan det blive rodet ret hurtigt, hvis du ikke har virksomhedens standarder på plads til oprettelse af arbejdsprocesser for GitHub-handlinger.
Som bedste praksis anbefaler vi, at du dokumenterer følgende i en GitHub-wiki eller som en Markdown-fil i et lager, der er tilgængeligt for alle i en organisation:
- Lagre til lager
- Navngivningskonventioner for filer/mapper
- Placering af delte komponenter
- Planer for løbende vedligeholdelse
- Retningslinjer for bidrag
Opret arbejdsprocesskabeloner
Arbejdsprocesskabeloner er en god måde at sikre, at automatisering genbruges og vedligeholdes i din virksomhed. Både i Enterprise Cloud og Enterprise Server kan brugere med skriveadgang til en organisations .github-lager oprette arbejdsprocesskabeloner, der vil være tilgængelige til brug for den anden organisations medlemmer med samme skriveadgang. Arbejdsprocesskabeloner kan derefter bruges til at oprette nye arbejdsprocesser i organisationens offentlige og private lagre.
Oprettelse af en arbejdsprocesskabelon udføres i to trin:
Opret en yml-arbejdsprocesfil.
Opret en json-metadatafil, der beskriver, hvordan skabelonen skal præsenteres for brugerne, når de opretter en arbejdsproces.
Seddel
Metadatafilen skal have samme navn som arbejdsprocesfilen. I stedet for filtypenavnet .yml skal den tilføjes med .properties.json. En fil med navnet octo-organization-ci.properties.json indeholder f.eks. metadataene for arbejdsprocesfilen med navnet octo-organization-ci.yml.
Begge filer skal placeres i et offentligt .github-lager og i en mappe med navnet arbejdsprocesskabeloner. Du skal muligvis oprette disse, hvis de ikke allerede findes i din organisation.
Følgende er et eksempel på en grundlæggende arbejdsprocesfil:
name: Octo Organization CI
on:
push:
branches: [ $default-branch ]
pull_request:
branches: [ $default-branch ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run a one-line script
run: echo Hello from Octo Organization
Bemærk, at den foregående fil bruger en pladsholder for $default-forgreninger. Når der oprettes en arbejdsproces ved hjælp af skabelonen, erstattes denne pladsholder automatisk med navnet på lagerets standardgren.
Følgende er den metadatafil, du ville oprette for arbejdsprocesfilen:
{
"name": "Octo Organization Workflow",
"description": "Octo Organization CI workflow template.",
"iconName": "example-icon",
"categories": [
"Go"
],
"filePatterns": [
"package.json$",
"^Dockerfile",
".*\\.md$"
]
}
Metadatafiler bruger følgende parametre:
| Parameter | Beskrivelse | Kræves |
|---|---|---|
| navn | Navnet på den arbejdsprocesskabelon, der vises på listen over tilgængelige skabeloner. | Ja |
| beskrivelse | Beskrivelse af den arbejdsprocesskabelon, der vises på listen over tilgængelige skabeloner. | Ja |
| iconName | Definerer et ikon for arbejdsprocessens post på skabelonlisten. Skal være et SVG-ikon med samme navn og skal gemmes i mappen med arbejdsprocesskabeloner. Der refereres f.eks. til en SVG-fil med navnet example-icon.svg som eksempelikon. | Nej |
| categories | Definerer sprogkategorien for arbejdsprocessen. Når en bruger får vist de tilgængelige skabeloner, vil de skabeloner, der svarer til det samme sprog, være mere fremtrædende. | Nej |
| filePatterns | Gør det muligt at bruge skabelonen, hvis brugerens lager har en fil i rodmappen, der svarer til et defineret regulært udtryk. | Nej |
Når en arbejdsprocesskabelon er oprettet, kan brugerne i din organisation finde den under Handlinger > Ny arbejdsproces > Arbejdsprocesser, der er oprettet af _your_organization_name.
Skabeloner, der kan genbruges til handlinger og arbejdsprocesser
GitHub Actions gør det muligt at automatisere arbejdsprocesser, og en vigtig del af effektiv administration af arbejdsprocesser er brug af skabeloner, der kan genbruges. Skabeloner, der kan genbruges, hjælper med at standardisere og strømline udviklingen på tværs af flere lagre, hvilket reducerer redundans og forbedrer vedligeholdelsen.
Skabeloner, der kan genbruges i GitHub-handlinger, refererer til foruddefinerede handlinger og arbejdsprocesser , der kan refereres til og bruges på tværs af flere projekter. De sikrer konsistens og overholdelse af virksomhedsstandarder.
Typer af skabeloner, der kan genbruges
| Skabelontype | Formål | Eksempel |
|---|---|---|
| Arbejdsprocesser, der kan genbruges | Standardiser CI/CD-pipelines på tværs af lagre. |
ci-pipeline.yml, deploy-app.yml |
| Handlinger, der kan genbruges | Indkapsling af almindelig automatiseringslogik. |
setup-env-action, security-scan-action |
| Arbejdsprocesskabeloner | Definer jobstrukturer, der kan genbruges. |
test-job.yml, build-job.yml |
Arbejdsprocesser, der kan genbruges
En arbejdsproces, der kan genbruges , er en arbejdsproces, der er defineret i et separat lager, som der kan refereres til i flere projekter. Dette gør det muligt for organisationer at centralisere deres CI/CD-logik.
Strukturen af en arbejdsproces, der kan genbruges
En arbejdsproces, der kan genbruges, gemmes i .github/workflows/ og bruger udløseren workflow_call .
Eksempel: Standardiseret CI-arbejdsproces (ci-pipeline.yml)
name: CI Pipeline
on:
workflow_call:
inputs:
node-version:
required: true
type: string
secrets:
npm-token:
required: true
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: ${{ inputs.node-version }}
registry-url: 'https://npm.pkg.github.com/'
- name: Install Dependencies
run: npm install
- name: Run Tests
run: npm test
Brug af en arbejdsproces, der kan genbruges i et andet lager
Når arbejdsprocessen, der kan genbruges, er defineret, kan den bruges i et hvilket som helst lager via nøgleordet uses: .
Eksempel: Kald af den arbejdsproces, der kan genbruges
name: Reusable CI Pipeline
on: push
jobs:
test:
uses: org/reusable-workflows/.github/workflows/ci-pipeline.yml@v1
with:
node-version: '16'
secrets:
npm-token: ${{ secrets.NPM_TOKEN }}
Fordele ved at bruge en arbejdsproces, der kan genbruges
- Sikrer, at alle lagre følger den samme CI/CD-struktur.
- Reducerer spild af redundans og vedligeholdelse.
- Giver mulighed for centraliserede opdateringer uden at ændre hvert lager.
Handlinger, der kan genbruges
En GitHub-handling er en modulopbygget enhed, der kan genbruges, og som udfører specifikke automatiseringsopgaver. Organisationer opretter ofte brugerdefinerede handlinger for at indkapsle den ofte anvendte logik.
Strukturen af en handling, der kan genbruges
Der er defineret en handling, der kan genbruges, i et handlingslager med en action.yml fil.
Eksempel: Handling for brugerdefineret installationsmiljø
name: "Setup Environment"
description: "Sets up Node.js and installs dependencies"
inputs:
node-version:
description: "Node.js version"
required: true
registry-url:
description: "NPM Registry URL"
required: false
default: "https://registry.npmjs.org/"
runs:
using: "node16"
main: "index.js"
Brug af en handling, der kan genbruges i en arbejdsproces
I stedet for at gentage konfigurationstrinnene i hver arbejdsproces bruger vi vores brugerdefinerede handling:
name: Build & Test
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Environment
uses: org/actions/setup-env@v1
with:
node-version: '16'
Fordele:
- Reducerer duplikering af konfigurationslogik på tværs af lagre.
- Forenkler arbejdsprocesfiler, hvilket gør dem mere læsevenlige.
- Centraliserer opdateringer – rettelser eller forbedringer på ét sted afspejler på tværs af alle arbejdsprocesser.
Arbejdsprocesskabeloner
Som beskrevet tidligere hjælper arbejdsprocesskabeloner med at standardisere automatisering på tværs af din organisation ved at levere foruddefinerede strukturer til almindelige opgaver. Disse skabeloner er en vigtig del af den bredere kategori af arbejdsprocesser, der kan genbruges.
I det tidligere afsnit "Opret arbejdsprocesskabeloner" skitserede vi, hvordan du opretter disse skabeloner ud fra en yml fil og en tilsvarende .properties.json metadatafil.
For yderligere at forbinde konceptet: Arbejdsprocesskabeloner er en form for arbejdsproces, der kan genbruges. Når du opretter og gemmer dem i et offentligt .github lager under workflow-templates/ mappen, giver de andre organisationsmedlemmer mulighed for at oprette ensartede arbejdsprocesser for deres lagre uden at skulle definere dem fra bunden.
Ved at udnytte arbejdsprocesskabeloner kan virksomheder:
- Gennemtving bedste praksis på tværs af lagre.
- Sæt fart på onboarding og konfiguration af nye projekter.
- Bevar konsistensen i CI/CD-processer.