Lär dig bygga GitHub Actions från grunden — workflow YAML, jobs, steps, custom actions, marknadsplatsen och CI/CD-automation.
GitHub Actions har 2026 blivit den självklara CI/CD-plattformen för miljontals utvecklare. Med över 20 000 actions på GitHub Marketplace och djup integration med resten av GitHub-ekosystemet är det första valet för automation — från enkel lintning till komplexa multi-miljö-deployments. Det bästa: du kan bygga dina egna anpassade actions återanvändbara över hela organisationen.
Den här guiden tar dig från ditt första workflow till att publicera en egen action på Marketplace. Vi täcker syntax, triggrar, jobs, caching, debugging och slutligen hur du bygger egna actions i Docker, JavaScript och som composite actions. Allt med praktiska exempel du kan använda direkt.
Vad är GitHub Actions?
GitHub Actions är en CI/CD- och automationstjänst inbyggd direkt i GitHub. Du definierar workflows i YAML-filer som placeras i .github/workflows/ i ditt repository. Varje workflow består av ett eller flera job som triggas av händelser som push, pull request, issue-kommentarer eller schemalagda tider. Jobben körs på GitHub-hostade runners (Linux, Windows, macOS) eller på egna self-hosted runners.
Fördelen med GitHub Actions jämfört med andra CI/CD-verktyg är den täta integrationen med GitHub: du får åtkomst till repository-händelser, secrets, miljövariabler och deployment-miljöer direkt i workflows. Det finns ingen extern tjänst att konfigurera — allt finns på samma plats som din kod.
Ditt första workflow — syntax och struktur
Skapa en fil .github/workflows/ci.yml i ditt repository:
| 1 | name: CI |
| 2 | on: |
| 3 | push: |
| 4 | branches: [main] |
| 5 | pull_request: |
| 6 | branches: [main] |
| 7 | |
| 8 | jobs: |
| 9 | test: |
| 10 | runs-on: ubuntu-latest |
| 11 | steps: |
| 12 | - uses: actions/checkout@v4 |
| 13 | - uses: actions/setup-node@v4 |
| 14 | with: |
| 15 | node-version: 22 |
| 16 | - run: npm ci |
| 17 | - run: npm test |
| 18 | - run: npm run build |
Detta workflow triggas vid push och pull request mot main-branchen. Jobbet test körs på en Ubuntu-runner, checkar ut koden, installerar Node.js 22, installerar beroenden, kör tester och bygger projektet. Varje step kan använda en färdig action (uses:) eller köra ett shell-kommando (run:).
Workflow-syntax — triggrar, job och steps
Triggrar (on:) kan vara enkla som push eller avancerade med filter för brancher, taggar och sökvägar. Du kan trigga workflows på nästan alla GitHub-händelser: issues, discussion, release, schedule (cron), workflow_dispatch (manuell trigg), och repository_dispatch (extern trigg).
Job kan köras parallellt eller sekventiellt med needs:. Varje job har tillgång till steps, env, strategy (för matrix-byggen) och if-villkor. Ett matrix-bygge låter dig testa mot flera versioner samtidigt:
| 1 | jobs: |
| 2 | test: |
| 3 | strategy: |
| 4 | matrix: |
| 5 | node-version: [18, 20, 22] |
| 6 | steps: |
| 7 | - uses: actions/setup-node@v4 |
| 8 | with: |
| 9 | node-version: ${{ matrix.node-version }} |
Caching och artefakter
För att snabba upp dina workflows använder du caching. actions/cache låter dig cachelagra beroenden mellan körningar:
| 1 | - uses: actions/cache@v4 |
| 2 | with: |
| 3 | path: ~/.npm |
| 4 | key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} |
| 5 | restore-keys: | |
| 6 | ${{ runner.os }}-node- |
Artefakter används för att spara filer mellan job eller efter en workflow-körning, till exempel byggda binärer eller testrapporter. Använd actions/upload-artifact och actions/download-artifact för att hantera artefakter. Artefakter sparas i 90 dagar som standard.
Secrets och miljövariabler
Känslig information som API-nycklar och lösenord lagras som secrets i GitHub: Settings > Secrets and variables > Actions. Referera dem i workflows med ${{ secrets.MITT_SECRET }}. Miljövariabler som inte är hemliga sätter du med env: på workflow-, job- eller step-nivå.
För deployment till olika miljöer (dev, staging, production) använder du GitHub Environments. Varje environment kan ha egna secrets, required reviewers och deployment-begränsningar. Kombinera environments med environment: i ditt job för att kontrollera deployments flöde.
Custom actions — tre typer
Du kan bygga tre typer av custom actions. Docker actions kör en Docker-container och är bra för åtgärder som har specifika systemsberoenden. JavaScript actions är snabbast och enklast — de körs direkt på runnern utan extra overhead. Composite actions kombinerar flera steps i en återanvändbar YAML-fil och är enklast att skapa.
Välj JavaScript actions som standard — de är snabba (inga Docker-builds), enkla att testa och kräver bara Node.js. Använd Docker actions när du behöver specifika OS-verktyg eller språk som inte finns på runnern. Använd composite actions för att gruppera vanliga step-sekvenser (t.ex. checkout + install + lint).
Bygg din första JavaScript action
JavaScript actions är Node.js-skript med en action.yml-manifestfil. Skapa ett repository my-action med följande struktur:
| 1 | # action.yml |
| 2 | name: "Min Action" |
| 3 | description: "Gör något användbart" |
| 4 | inputs: |
| 5 | who-to-greet: |
| 6 | description: "Vem ska hälsas?" |
| 7 | required: true |
| 8 | default: "Världen" |
| 9 | outputs: |
| 10 | time: |
| 11 | description: "Hälsningstidpunkten" |
| 12 | runs: |
| 13 | using: "node20" |
| 14 | main: "index.js" |
Och index.js:
| 1 | const core = require("@actions/core") |
| 2 | const github = require("@actions/github") |
| 3 | try { |
| 4 | const name = core.getInput("who-to-greet") |
| 5 | core.setOutput("time", new Date().toISOString()) |
| 6 | core.notice(`Hej ${name}!`) |
| 7 | } catch (error) { |
| 8 | core.setFailed(error.message) |
| 9 | } |
Publicera till Marketplace eller använd den direkt från ett annat repo: - uses: ditt-anvandarnamn/my-action@v1.
Testa och felsök dina actions
För att testa dina workflows lokalt använder du act — ett verktyg som kör GitHub Actions lokalt med Docker. Installera med brew install act (macOS) eller ladda ner från GitHub Releases. Kör act -j test för att köra ett specifikt job. act stöder secrets via .secrets-fil och olika runner-typer.
För felsökning i riktiga workflows använder du ACTIONS_STEP_DEBUG-secretet satt till true. Det aktiverar detaljerad loggning för varje step. Du kan också använda core.debug() i din action för anpassad debug-utdata. För problem med caching, kontrollera cache-key och om cachen träffas genom att inspektera loggarna.
Arbetsflöden för CI/CD
Ett typiskt CI/CD-flöde med GitHub Actions har flera job: lint → test → bygg → deploy. De olika jobben körs sekventiellt med needs: och varje job kan ha olika runners och miljövariabler. Här är ett mer avancerat exempel:
| 1 | jobs: |
| 2 | lint: |
| 3 | runs-on: ubuntu-latest |
| 4 | steps: |
| 5 | - uses: actions/checkout@v4 |
| 6 | - run: npm run lint |
| 7 | |
| 8 | test: |
| 9 | needs: lint |
| 10 | runs-on: ubuntu-latest |
| 11 | strategy: |
| 12 | matrix: |
| 13 | node: [18, 20, 22] |
| 14 | steps: |
| 15 | - uses: actions/checkout@v4 |
| 16 | - uses: actions/setup-node@v4 |
| 17 | with: { node-version: ${{ matrix.node }} } |
| 18 | - run: npm ci |
| 19 | - run: npm test |
| 20 | |
| 21 | deploy: |
| 22 | needs: test |
| 23 | if: github.ref == 'refs/heads/main' |
| 24 | runs-on: ubuntu-latest |
| 25 | environment: production |
| 26 | steps: |
| 27 | - uses: actions/checkout@v4 |
| 28 | - run: npm run deploy |
Publicera actions på Marketplace
När din action fungerar kan du publicera den på GitHub Marketplace. Skapa ett public repository för action, lägg till en README med dokumentation och användningsexempel, och skapa en release med semantisk versionsnumrering. GitHub upptäcker automatiskt att repot innehåller en action och visar en "Publish to Marketplace"-knapp.
Innan publicering, se till att din action har: en tydlig action.yml med alla inputs och outputs dokumenterade, en README med användningsexempel, och ett exempelworkflow. Tagga releaser med v1, v1.2 och v1.2.3 för att följa semver — användare kan då välja mellan major-version (@v1) och specifik version (@v1.2.3).
Bästa praxis och prestandaoptimering
För att få ut mesta möjliga av GitHub Actions, följ dessa rekommendationer: håll workflows fokuserade — ett workflow per uppgift (test, bygg, deploy) är lättare att underhålla än ett monster-workflow. Använd caching flitigt för att minska körningstider. Sätt timeout-minutes på job för att undvika evighetsloopar. Använd if:-villkor för att hoppa över onödiga steps.
Använd GitHub Actions för mycket mer än CI/CD: automatisera issue-hantering, skapa release-notes, synkronisera forks, köra schemalagda säkerhetskontroller, och mycket mer. Med workflow_dispatch kan du skapa manuella workflows som utför underhållsuppgifter. Och glöm inte att använda organisationens actions policies för att styra vilka actions era team får använda.
Sammanfattning
GitHub Actions är en extremt kraftfull plattform för automation som går långt bortom traditionell CI/CD. Med enkel YAML-syntax, tusentals färdiga actions och möjligheten att bygga egna har du verktygen för att automatisera nästan allt i din utvecklingsprocess. Börja enkelt med ett grundläggande CI-workflow, experimentera med anpassade actions, och bygg gradvis upp en automation som spara timmar varje vecka.
“GitHub Actions är 2026 års motor för utvecklingsautomation — från enkel CI till komplexa multi-miljö-deployments.”
- Simon Axelsson
Vanliga frågor
- Hur mycket kostar GitHub Actions?
- GitHub Actions är gratis för publika repositories. För privata repositories ingår 2 000 minuter per månad på Free-planen, 3 000 minuter på Team ($4/person/månad) och 50 000 minuter på Enterprise. Minuterna inkluderar Linux-runners; Windows och macOS kostar 2x respektive 10x.
- Kan jag köra GitHub Actions på egen infrastruktur?
- Ja, med self-hosted runners. Installera runner-agenten på din egen maskin, registrera den i ditt repository eller organisation, och workflows kommer automatiskt att använda den. Self-hosted runners är bra för att få tillgång till internt nätverk, specifik hårdvara eller lägre kostnader vid många körningar.
- Vad är skillnaden mellan en action och ett workflow?
- Ett workflow är den övergripande automatiseringsprocessen definierad i en YAML-fil. En action är en återanvändbar enhet som utför en specifik uppgift (t.ex. checkout av kod eller installation av Node.js). Ett workflow använder actions i sina steps. Du skapar ett workflow; du skapar eller använder actions.
- Hur felsöker jag en GitHub Action som misslyckas?
- Börja med att läsa workflow-loggen i GitHub Actions-fliken. Aktivera debug-loggning genom att sätta en secret <code>ACTIONS_STEP_DEBUG=true</code>. För lokala tester använder du <code>act</code>. Kontrollera secrets, miljövariabler och om rätt branch används. För Docker-actions, kontrollera att Dockerfile bygger korrekt lokalt.
- Hur versionshanterar jag mina actions?
- Använd semantisk versionsnumrering (semver). Tagga releaser med <code>v1.0.0</code>, <code>v1.1.0</code> etc. Uppdatera major-taggen (<code>v1</code>) för att peka på senaste releasen i den grenen. Användare refererar sedan action med <code>@v1</code> (automatiska uppdateringar) eller <code>@v1.2.3</code> (låst version). Dokumentera brytande ändringar i release-notes.
Om författaren
Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.
Fler artiklar av Simon