Een aangepaste GitHub-actie maken

Voltooid

GitHub Actions is een krachtige functie waarmee u van code naar de cloud kunt gaan, allemaal vanuit het comfort en gemak van uw eigen opslagplaats. Hier vindt u informatie over de verschillende typen GitHub-acties en de metagegevens, syntaxis en werkstroomopdrachten voor het maken van aangepaste GitHub-acties.

Typen GitHub-acties

Acties zijn afzonderlijke taken die u kunt gebruiken om uw ontwikkelwerkstromen aan te passen. U kunt uw eigen acties maken door aangepaste code te schrijven die communiceert met uw opslagplaats om aangepaste taken uit te voeren of door acties te gebruiken die door de GitHub-communityshares worden gedeeld. Als u door verschillende acties navigeert, ziet u dat er drie verschillende soorten acties zijn: Docker-containeracties, JavaScript-acties en acties voor samengestelde uitvoeringsstappen. Laten we elk actietype nader bekijken.

Docker-containeracties

Docker-containers verpakken de omgeving met de GitHub Actions-code. Dit betekent dat de actie wordt uitgevoerd in een consistente en betrouwbare omgeving, omdat alle afhankelijkheden zich binnen die container bevinden. Als de actie moet worden uitgevoerd in een specifieke omgevingsconfiguratie, zijn Docker-containers een goede manier om te gaan, omdat u het besturingssysteem en hulpprogramma's kunt aanpassen. Het nadeel is dat omdat de taak de container moet bouwen en ophalen, Docker-containeracties vaak trager zijn dan JavaScript-acties.

Voordat u een Docker-containeractie bouwt, moet u enige basiskennis hebben van het gebruik van omgevingsvariabelen en het Docker-containerbestandssysteem. De stappen die u moet uitvoeren om een Docker-containeractie te bouwen, zijn vervolgens minimaal en eenvoudig:

1. Maak een Dockerfile opdracht om de opdrachten te definiëren voor het samenstellen van de Docker-installatiekopieën.
2. Maak een action.yml metagegevensbestand om de invoer en uitvoer van de actie te definiëren. Stel de runs: using: waarde docker in op en de runs: image: waarde Dockerfile in het bestand.
3. Maak een entrypoint.sh bestand om de docker-installatiekopieën te beschrijven.
4. Voer uw actie door naar GitHub en push deze met de volgende bestanden: action.yml, entrypoint.sh, Dockerfileen README.md.

JavaScript-acties

JavaScript-acties kunnen rechtstreeks op de runner-machine worden uitgevoerd en de actiecode scheiden van de omgeving die wordt gebruikt om de actie uit te voeren. Hierdoor wordt de actiecode vereenvoudigd en kan deze sneller worden uitgevoerd dan acties binnen een Docker-container.

Als vereiste voor het maken en gebruiken van verpakte JavaScript-acties moet u Node.js downloaden, waaronder npm. Als een optionele stap (maar een die we aanbevelen) is om GitHub Actions Toolkit Node.js te gebruiken. Dit is een verzameling Node.js pakketten waarmee u snel JavaScript-acties kunt bouwen met meer consistentie.

De stappen voor het bouwen van een JavaScript-actie zijn minimaal en eenvoudig:

1. Maak een action.yml metagegevensbestand om de invoer en uitvoer van de actie te definiëren en laat de actieloper weten hoe deze JavaScript-actie moet worden uitgevoerd.
2. Maak een index.js bestand met contextinformatie over de Toolkit-pakketten, routering en andere functies van de actie.
3. Voer uw actie door en push deze naar GitHub met de volgende bestanden: action.yml, , index.jsnode_modules, package.json, , package-lock.jsonen README.md.

Acties voor stappen voor samengestelde uitvoering

Met acties voor samengestelde uitvoeringsstappen kunt u acties opnieuw gebruiken met behulp van shellscripts. U kunt zelfs meerdere shelltalen combineren binnen dezelfde actie. Als u veel shellscripts hebt om verschillende taken te automatiseren, kunt u deze nu eenvoudig omzetten in een actie en ze opnieuw gebruiken voor verschillende werkstromen. Soms is het eenvoudiger om alleen een shellscript te schrijven dan javaScript te gebruiken of uw code in een Docker-container te verpakken.

Verpakte samengestelde actie

Verpakte samengestelde acties bundelen meerdere stappen in een herbruikbare eenheid. Deze acties worden gedefinieerd in een opslagplaats en kunnen worden verwezen in werkstromen in verschillende opslagplaatsen. Het verpakken van een samengestelde actie vereenvoudigt werkstromen, vermindert duplicatie en verbetert de onderhoudbaarheid.

Bij het maken van een verpakte samengestelde actie worden de stappen gedefinieerd in één action.yml bestand. Dit bestand geeft de invoer, uitvoer en de reeks opdrachten of acties op die moeten worden uitgevoerd. Verpakte samengestelde acties zijn met name handig voor het automatiseren van terugkerende taken of het combineren van meerdere shellopdrachten in één herbruikbare actie.

Een samengestelde qction maken

1. Maak een map aan voor de samengestelde actie

Je moet je samengestelde actie in een eigen map binnen de repository plaatsen.

Voorbeeld van mapstructuur:

.github/actions/my-composite-action/
├── action.yml
└── scripts/
    └── my-script.sh

2. Definieer het action.yml bestand

Maak een bestand in de action.yml.

name: "My Composite Action"
description: "A reusable composite action that checks out code and sets up Node.js"

inputs:
  node-version:
    description: "The Node.js version to use"
    required: true

runs:
  using: "composite"
  steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Set up Node.js
      uses: actions/setup-node@v4
      with:
        node-version: ${{ inputs.node-version }}

Notitie: Het veld using: samengesteld geeft aan dat deze actie een samengestelde actie is.

3. Gebruik de samengestelde actie in een werkstroom

Zodra de samengestelde actie is gemaakt, kan ernaar worden verwezen in een GitHub Actions-werkstroom.

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Use my composite action
        uses: ./.github/actions/my-composite-action
        with:
          node-version: '18'

Als uw samengestelde actie wordt gedeeld vanuit een andere opslagplaats, raadpleegt u deze als volgt:

uses: owner/repository/.github/actions/my-composite-action@v1

Uitvoer toevoegen aan een samengestelde actie

Samengestelde acties kunnen uitvoer definiëren die werkstromen kunnen gebruiken om gegevens tussen stappen of taken door te geven. Uitvoer is met name handig voor het delen van resultaten of berekende waarden van de ene actie naar de andere.

In het volgende voorbeeld ziet u hoe u een uitvoer in een samengestelde actie definieert en gebruikt:

Een uitvoer definiëren in action.yml

Het action.yml bestand geeft een uitvoer met de naam script-result. Met deze uitvoer wordt de waarde opgehaald uit de result uitvoer van de run-script stap. In run-script de stap wordt een Bash-opdracht uitgevoerd om de uitvoerwaarde in te stellen.

outputs:
  script-result:
    description: "Result from the script"
    value: ${{ steps.run-script.outputs.result }}

runs:
  using: "composite"
  steps:
    - id: run-script
      run: echo "result=Success" >> $GITHUB_OUTPUT
      shell: bash

De uitvoer in een werkstroom gebruiken

Zodra de samengestelde actie is gemaakt, kan de uitvoer worden geopend in een werkstroom. Hier is een voorbeeld:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Run composite action
        id: my-action
        uses: ./.github/actions/my-composite-action

      - name: Display result
        run: echo "Script Result: ${{ steps.my-action.outputs.script-result }}"

In dit voorbeeld:

• De samengestelde actie wordt aangeroepen met behulp van het uses trefwoord.
• Open de uitvoer script-result met behulp van de steps.<step-id>.outputs.<output-name> syntaxis.
• Het resultaat weergeven in de werkstroomlogboeken.

Definieer uitvoer in samengestelde acties om herbruikbare en modulaire werkstromen te maken. Deze aanpak vereenvoudigt het delen van gegevens en verbetert de onderhoudbaarheid.

Aanbevolen procedures voor samengestelde acties

Beste werkwijze	Beschrijving
Versiebeheer gebruiken	Gebruik een v1 tag om te verwijzen naar stabiele versie 1.
Acties modulair houden	Groepsgerelateerde stappen binnen een samengestelde actie.
Documentinvoer en uitvoer	Beschrijvingen toevoegen voor invoer/uitvoer in action.yml.
Testen voor publicatie	Valideer de samengestelde actie in een testopslagplaats.

Samengestelde actie in een werkstroom

Samengestelde acties zijn een krachtige manier om werkstromen te vereenvoudigen door meerdere stappen in een herbruikbare eenheid te bundelen. Met deze acties kunt u een reeks opdrachten of acties in één action.yml bestand definiëren, zodat u logica eenvoudiger kunt onderhouden en opnieuw kunt gebruiken in verschillende werkstromen.

Voordelen van samengestelde acties:

• Herbruikbaarheid : definieer acties eenmaal en gebruik ze in meerdere werkstromen.
• Onderhoudbaarheid : verminder duplicatie door logica in één actie te centraliseren.
• Modulariteit : combineer meerdere shellopdrachten of andere acties in één eenheid.

Een actie maken om een CLI in te stellen op GitHub Actions-runners

Veel CI/CD-werkstromen vereisen een specifieke versie van een CLI-hulpprogramma om te communiceren met cloudservices, infrastructuur te beheren of scripts uit te voeren. Hoewel gitHub-gehoste runners vooraf zijn geïnstalleerd met veel hulpprogramma's, bevatten ze mogelijk niet de exacte versie die uw werkstroom nodig heeft, met name als het een oudere of niet-ondersteunde versie is. In plaats van de vereiste CLI-versie in elke werkstroom te installeren, kunt u een herbruikbare GitHub-actie maken die:

• Zorgt voor een consistente installatie van de vereiste CLI-versie voor alle taken.
• Vereenvoudigt werkstromen door de installatielogica te centraliseren.
• Optimaliseert caching voor snellere uitvoering van werkstromen.

Een CLI-installatieactie ontwikkelen

Een CLI-installatieactie is een op JavaScript gebaseerde actie waarmee een CLI op een GitHub-runner wordt geïnstalleerd en geconfigureerd.

Stappen voor het maken van de actie:

Stap 1: De actiemap instellen

Voer de volgende stappen uit om de map voor de CLI-installatieactie handmatig te maken:

1. Ga naar uw opslagplaats

2. Een nieuwe map maken voor de actie
   Maak een nieuwe map met de naam my-cli-action in de .github/actions map. Dit zorgt ervoor dat uw actie is georganiseerd en de aanbevolen structuur van GitHub volgt voor aangepaste acties.

3. Ga naar de nieuwe map
   Ga naar de zojuist gemaakte map om bestanden toe te voegen voor uw actie:

4. De directorystructuur controleren
   Nadat u de map hebt gemaakt, moet de structuur van de opslagplaats er als volgt uitzien:

your-repository/
├── .github/
│   ├── actions/
│   │   ├── my-cli-action/

U bent nu klaar om door te gaan met het maken van het action.yml bestand en andere benodigde bestanden voor de CLI-installatieactie.

Stap 2: het action.yml metagegevensbestand definiëren

Maak een action.yml-bestand om de actie te beschrijven.

name: "Setup MyCLI"
description: "Installs MyCLI and adds it to the PATH"
author: "Your Name"

inputs:
  version:
    description: "The CLI version to install"
    required: false
    default: "latest"

runs:
  using: "node16"
  main: "index.js"

Waarom gebruiken met: node16? Met deze actie wordt JavaScript-code uitgevoerd met Node.js 16.

Stap 3: Een JavaScript-script maken om de CLI te installeren

Maak in dezelfde map een bestand met de naam index.js en voeg de volgende code toe:

const core = require('@actions/core');
const { execSync } = require('child_process');

async function run() {
  try {
    const version = core.getInput('version') || 'latest';
    
    console.log(`Installing MyCLI version: ${version}...`);

    execSync(`curl -fsSL https://cli.example.com/install.sh | sh`, { stdio: 'inherit' });

    console.log("MyCLI installed successfully.");
  } catch (error) {
    core.setFailed(`Installation failed: ${error.message}`);
  }
}

run();

De bovenstaande JavaScript-code maakt gebruik van core.getInput() om de CLI-versie op te halen die is opgegeven als invoer. Vervolgens wordt een curl-opdracht uitgevoerd om de CLI te downloaden en te installeren. Als het installatieproces mislukt, gebruikt de actie core.setFailed() om de werkstroom als mislukt te markeren.

Stap 4: De actie lokaal testen

Voordat u de actie in een werkstroom gebruikt, test u deze op een door GitHub gehoste runner.
Maak een werkstroombestand (.github/workflows/test.yml) in uw opslagplaats:

name: Test MyCLI Setup

on:
  push:
    branches:
      - main
      - feature/*

1. De werkstroom activeren
De werkstroom wordt geactiveerd bij pushes naar de hoofdvertakking en elke vertakking die overeenkomt met het feature/*-patroon. U kunt dit aanpassen aan de vertakkingsstrategie van uw opslagplaats.

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

2. Kloon de opslagplaats
De actions/checkout@v4 actie wordt gebruikt om de repository naar de runner te klonen. Dit zorgt ervoor dat de werkstroom toegang heeft tot de bestanden van de opslagplaats.

      - name: Install MyCLI
        uses: ./.github/actions/my-cli-action
        with:
          version: '1.2.3'

3. Voer de aangepaste actie uit
Het gebruik: ./.github/actions/my-cli-action line verwijst lokaal naar de aangepaste actie. Zorg ervoor dat de actiemap en het action.yml-bestand correct zijn ingesteld. De versie-invoer geeft de CLI-versie op die moet worden geïnstalleerd, in dit geval versie 1.2.3.

      - name: Verify CLI Installation
        run: |
          echo "Checking MyCLI version..."
          mycli --version

4. Controleer de CLI-installatie
Met deze stap wordt een shell-opdracht uitgevoerd om te controleren of de CLI is geïnstalleerd. De versie van de geïnstalleerde CLI wordt gecontroleerd door mycli --version uit te voeren.

Lokaal testen

Als u deze werkstroom lokaal wilt testen, gebruikt u het act CLI-hulpprogramma:

act -j test

Hiermee wordt de GitHub Actions-omgeving op uw lokale computer gesimuleerd, zodat u fouten in de werkstroom kunt opsporen en valideren voordat u wijzigingen pusht.

Optimalisatietip: Caching

Als u de werkstroomprestaties wilt verbeteren, slaat u de CLI-installatiemap in de cache op met behulp van de actions/cache actie:

      - name: Cache MyCLI
        uses: actions/cache@v4
        with:
          path: ~/.mycli
          key: mycli-${{ runner.os }}-${{ inputs.version }}

Dit zorgt ervoor dat volgende uitvoeringen de CLI-installatie in de cache opnieuw gebruiken, waardoor de installatietijd wordt verkort.

Aanbevolen procedures voor CLI-installatieacties

Beste praktijk	Beschrijving
Versiebeheer gebruiken	Gebruikers toestaan een CLI-versie op te geven via inputs.version.
Fouten correct verwerken	Gebruik core.setFailed() om bij fouten te stoppen.
Cache CLI-installatie	Werkstroomprestaties optimaliseren met behulp van actions/cache.
Documentatie opgeven	Gebruik en invoer uitleggen in README.md.

Problemen met JavaScript-acties oplossen

Wanneer u werkt met GitHub Actions op basis van JavaScript, kunnen er onverwacht gedrag, fouten of fouten optreden tijdens de uitvoering van de werkstroom. Deze les biedt technieken en hulpprogramma's waarmee u problemen in uw JavaScript-acties kunt identificeren en oplossen.

Veelvoorkomende scenario's voor probleemoplossing

Probleem	Mogelijke oorzaak	Voorgestelde oplossing
De actie mislukt met een stack trace	Syntaxis- of runtime-fout in index.js	Gebruik console.log() en controleer de logbestanden
Invoer is undefined	Onjuiste invoernaam of ontbrekende invoer	Verifieer action.yml en hoe de invoer wordt doorgegeven
Omgevingsvariabelen zijn niet ingesteld	core.exportVariable of process.env niet goed gebruikt	De code-instelling van de variabelen controleren
Bestand niet gevonden	Ontbrekende relatieve paden	Gebruik __dirname of volledige paden naar bestanden
Cache wordt niet hersteld	Verkeerde key waarden of path waarden	Cacheconfiguratie en -sleutels controleren

Logboekregistratie gebruiken voor foutopsporing

Logberichten vastleggen met core.info, core.debug en console.log

const core = require('@actions/core');

core.info("This is an info message");
core.debug("This is a debug message");
console.log("This is a raw console log");

✅ Gebruik core.debug voor foutopsporingslogboeken. Deze worden alleen weergegeven wanneer ACTIONS_STEP_DEBUG is ingesteld op waar.

Logboekregistratie voor foutopsporing inschakelen

U kunt foutopsporingslogboeken op stapniveau inschakelen door het volgende geheim in te stellen:

ACTIONS_STEP_DEBUG=true

Als u diagnostische logboeken voor runners wilt inschakelen, stelt u het volgende in:

ACTIONS_RUNNER_DEBUG=true

Geheimen instellen voor foutopsporing

1. Ga naar uw GitHub-opslagplaats.
2. Navigeer naar >> envariabelenacties.
3. Voeg nieuwe geheimen toe met de volgende namen en waarden:
   • ACTIONS_STEP_DEBUG: true
   • ACTIONS_RUNNER_DEBUG: true

Werkstroomlogboeken controleren

Wanneer een werkstroom mislukt, klikt u op de mislukte taak op het tabblad Acties. Vouw elke stap uit naar:

• Gedetailleerde logboeken weergeven
• Standaarduitvoer controleren (stdout)
• Bekijk de afsluitcode van scripts
• Niet-verwerkte uitzonderingen identificeren

🔍 Voorbeeld van logboekuitvoer

Error: Cannot find module '@actions/core'
Require stack:
- /home/runner/work/_actions/my-org/my-action/index.js

✅ Oplossing: Voer npm install @actions/core en commit node_modules uit (of gebruik ncc om de actie te bundelen).

Uw actie lokaal testen

Act gebruiken: een CLI-hulpprogramma om GitHub Actions lokaal uit te voeren. Voorbeeld:

act -j test

🛠 Zorg ervoor dat u uw GitHub-omgeving correct simuleert bij het lokaal testen.

Fouten probleemloos verwerken

Uitzonderingen vangen en mislukken met nuttige berichten:

try {
  // your logic
} catch (error) {
  core.setFailed(`Action failed with error: ${error.message}`);
}

🔁 Dit zorgt ervoor dat GitHub de werkstroom stopt bij een fout en leesbare logboeken biedt.

Aanbevolen procedures voor het opsporen van fouten in JavaScript-acties

Praktijk	Beschrijving
Core.debug() gebruiken	Verberg gedetailleerde logberichten, tenzij debugging is ingeschakeld.
Action.yml valideren	Zorg ervoor dat de invoer en uitvoer juist zijn gedefinieerd.
Bundelcode	Gebruik @vercel/ncc dit om JavaScript in één bestand te compileren. Dit vermindert afhankelijkheden en zorgt ervoor dat alle vereiste modules worden opgenomen, waardoor runtimefouten worden voorkomen die worden veroorzaakt door ontbrekende bestanden.
Testen met actie	Uitvoeringen lokaal simuleren voor snellere iteraties.
Try/catch gebruiken	Voorkomen dat werkstromen op de achtergrond mislukken.

Problemen met Docker-containeracties oplossen

Docker-containeracties zijn krachtig voor het inkapselen van complexe hulpprogramma's en omgevingen in GitHub Actions-werkstromen. Het opsporen van fouten in deze acties kan echter lastiger zijn dan JavaScript-acties vanwege hun geïsoleerde runtime-omgeving. In deze les wordt u begeleid bij het identificeren, diagnosticeren en oplossen van problemen met op Docker gebaseerde acties.

Veelvoorkomende problemen in Docker-containeracties

Probleem	Oorzaak	Voorgestelde oplossing
De actie kan niet worden gestart	ENTRYPOINT of CMD onjuist geconfigureerd	Controleer of Dockerfile correct wordt gebruikt ENTRYPOINT
Ontbrekende afhankelijkheden	Afhankelijkheden zijn niet geïnstalleerd of onjuist geconfigureerd	Zorg ervoor dat alle pakketten zijn geïnstalleerd in de afbeelding
Invoer niet ontvangen	INPUT_ omgevingsvariabelen niet benaderd	Gebruik process.env.INPUT_<INPUT_NAME> (of shell-equivalent)
Bestand niet gevonden	Onjuist bestandspad in container	Absolute paden gebruiken of mapstructuur valideren
Machtiging geweigerd	Het bestand of script heeft geen uitvoeringsmachtiging	Voeg RUN chmod +x <script> toe in Dockerfile
Netwerkgerelateerde fouten	Externe services zijn niet toegankelijk	Netwerkinstellingen valideren en logica voor opnieuw proberen

De levenscyclus van docker-acties begrijpen

Voordat u problemen gaat oplossen, is het handig om te begrijpen hoe Docker-containeracties worden uitgevoerd.

Trigger voor werkstroom

Een GitHub Actions-werkstroom wordt gestart als reactie op een geconfigureerde gebeurtenis, zoals een push, pull_requestof handmatig workflow_dispatch.

2. Runner-Configuratie

GitHub richt een nieuwe virtuele machine (de runner) in om de werkstroom uit te voeren. De runner bereidt de omgeving voor door actiedefinities te downloaden en afhankelijkheden op te lossen.

3. Actieafhandeling

Als de actie runs.using: docker specificeert in het action.yml bestand, herkent GitHub deze als een op Docker gebaseerde actie.

4. Build of pull een afbeelding

GitHub bouwt de Docker-installatiekopie die is gedefinieerd in de actie Dockerfile of haalt een vooraf gemaakte installatiekopie op, indien opgegeven. Deze afbeelding definieert de omgeving waarin de actiecode wordt uitgevoerd.

5. Containeruitvoering

De runner start de Docker-container, koppelt de werkruimte en injecteert omgevingsvariabelen, inclusief geheime gegevens en invoergegevens die in de werkstroom zijn gedefinieerd.

6. Invoerpuntuitvoeringen

GitHub voert de entrypoint opdracht uit vanuit het Dockerfile in de container. Hier wordt de aangepaste actielogica uitgevoerd, meestal een script of toepassing.

7. Verwerking van resultaten

Uitvoer die door de containeractie wordt ingesteld, wordt vastgelegd door de runner en doorgegeven aan de volgende stappen in de werkstroom. Zodra het is voltooid, wordt de container uitgeschakeld en wordt de runner verwijderd.

Opmerking: Docker-containeracties worden uitgevoerd in een schone, geïsoleerde omgeving. Bestandssysteemstatus, geïnstalleerde hulpprogramma's en omgevingsvariabelen moeten allemaal worden gedefinieerd in het Dockerfile.

Foutopsporingstechnieken

1. Logboekregistratie toevoegen

Gebruik echo-, printf- of loginstructies in uw entrypoint-script.

echo "Starting Docker action..."
echo "Input VALUE: $INPUT_VALUE"

Registreer alle kritieke invoer en stappen om te diagnosticeren waar de fout optreedt.

2. Lokaal bouwen en testen

Gebruik Docker op uw computer om het gedrag van de container te simuleren:

docker build -t my-action .
docker run -e INPUT_NAME=value my-action

Zorg ervoor dat omgevingsvariabelen de gitHub-sets nabootsen.

3. Gebruik de ACT CLI om GitHub-werkstromen te simuleren

Installeer act om uw GitHub-werkstromen lokaal uit te voeren:

act -j test-job

Ideaal voor het testen van Docker-acties in werkstromen zonder naar GitHub te pushen.

4. Configuratie van Dockerfile valideren

Zorg ervoor dat u ENTRYPOINT of CMD definieert. Kopieer uw scripts naar de installatiekopie en geef ze de volgende machtiging:

COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

5. GitHub-logboeken inspecteren

Klik op een mislukte werkstroomuitvoering, vouw elke stap uit en bekijk het volgende:

• Docker-buildlogboeken
• Standaarduitvoer en standaardfout van de container
• Afsluitcodes en stacktraceringslogboeken 🔍 laten vaak ontbrekende pakketten, syntaxisproblemen of machtigingsfouten zien.

Voorbeeld: Fout bij invoerpunt

Error: container_linux.go:380: starting container process caused "exec: \"/entrypoint.sh\": permission denied"

✅ Oplossing: RUN chmod +x /entrypoint.sh toevoegen in uw Dockerfile.

Toewijzing van omgevingsvariabelen

GitHub-invoer	Docker-omgevingsvariabele
with: name: test	INPUT_NAME=test
GITHUB_WORKSPACE	Toegewezen aan /github/workspace
GITHUB_EVENT_NAME	Gebeurtenis die de werkstroom heeft geactiveerd

echo "Input was $INPUT_NAME"
echo "Working dir: $GITHUB_WORKSPACE"

Geheimen voor probleemoplossing gebruiken

Schakel extra logboekregistratie in door deze geheimen toe te voegen aan uw opslagplaats of organisatie:

Geheim	Omschrijving
ACTIONS_STEP_DEBUG	Logboekregistratie voor foutopsporing inschakelen
ACTIONS_RUNNER_DEBUG	Hiermee schakelt u diagnostische gegevens van runners in

Aanbevolen procedures voor foutopsporing in Docker

Beste werkwijze	Waarom
Logboekregistratie uitgebreid gebruiken	Helpt bij het traceren van foutpunten
Altijd chmod +x instellen	Machtigingsfouten voor shellscripts voorkomen
Invoer valideren in uw script	Ontbrekende of onjuiste invoer vroegtijdig detecteren
Containerafhankelijkheden minimaliseren	Kleinere afbeeldingen zijn eenvoudiger om fouten op te sporen
Lokaal testen met docker-uitvoering of -actie	Snellere iteraties en directe feedback