Skip to main content

Diese Version von GitHub Enterprise Server wurde eingestellt am 2024-07-09. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Von Jenkins zu GitHub-Aktionen migrieren

GitHub Actions und Jenkins haben mehrere Ähnlichkeiten, was die Migration zu GitHub Actions relativ einfach macht.

Hinweis: GitHub-gehostete Runner werden auf GitHub Enterprise Server derzeit nicht unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der GitHub public roadmap.

Einführung

Jenkins und GitHub Actions ermöglichen es Dir, Workflows zu erstellen, die automatisch Code bauen, testen, publizieren, freigeben und bereitstellen. Jenkins und GitHub Actions haben einige Ähnlichkeiten in der Workflow-Konfiguration:

  • Jenkins erstellt Workflows mit deklarativen Pipelines, die den Workflowdateien in GitHub Actions ähneln.
  • Jenkins verwendet Phasen, um eine Reihe von Schritten auszuführen, während GitHub Actions Aufträge verwendet, um Schritte oder einzelne Befehle zu gruppieren.
  • Jenkins und GitHub Actions unterstützen Container-basierte Builds. Weitere Informationen findest du unter Creating a Docker container action (Erstellen einer Docker-Containeraktion).
  • Schritte oder Aufgaben können wiederverwendet und in der Community gemeinsam genutzt werden.

Weitere Informationen findest du unter Grundlegendes zu GitHub Actions.

Wichtige Unterschiede

  • Jenkins hat zwei Arten von Syntax zur Erzeugung von Pipelines: Deklarative Pipeline und „Scripted“ (Skript-basierte) Pipeline. GitHub Actions verwendet YAML, um Workflows und Konfigurationsdateien zu erstellen. Weitere Informationen findest du unter Workflowsyntax für GitHub Actions.
  • Die Deployments von Jenkins ist üblicherweise selbst-gehosted, wobei die Benutzer die Server in ihren eigenen Rechenzentren betreuen. GitHub Actions bieten einen hybriden Cloud-Ansatz, indem sie ihre eigenen Runner betreiben, die du zum Ausführen von Jobs verwenden kannst, während sie auch selbst-gehostete Läufer unterstützen. Weitere Informationen findest du unter Informationen zu selbstgehosteten Runnern.

Funktionaltäten im Vergleich

Deine Builds verteilen

Mit Jenkins kannst Du Builds an einen einzelnen Build-Agenten senden oder sie über mehrere Agenten verteilen. Du kannst diese Agenten auch nach verschiedenen Attributen klassifizieren, wie zum Beispiel Arten von Betriebssystemen.

In ähnlicher Weise kann GitHub Actions Aufträge an von GitHub gehostete oder an selbstgehostete Runner senden, und du kannst Bezeichnungen verwenden, um die Runner nach verschiedenen Attributen zu klassifizieren. Weitere Informationen findest du unter Grundlegendes zu GitHub Actions und unter Informationen zu selbstgehosteten Runnern.

Sektionen verwenden, um Pipelines zu organisieren

Jenkins teilt seine Deklarative Pipelines in mehrere Sektionen auf. In ähnlicher Weise strukturiert GitHub Actions seine Workflows in separaten Sektionen. Die folgende Tabelle vergleicht Sektionen bei Jenkins mit dem Workflow bei GitHub Actions.

Anweisungen in JenkinsGitHub Actions
agentjobs.<job_id>.runs-on
jobs.<job_id>.container
postKeine
stagesjobs
stepsjobs.<job_id>.steps

using-Direktiven

Jenkins verwendet Anweisungen, um deklarative Pipelines zu verwalten. Diese Anweisungen definieren die Merkmale Deines Workflows und die Art und weise, wie dieser ausgeführt wird. Die folgende Tabelle zeigt, wie diese Anweisungen den Konzepten innerhalb von GitHub Actions entsprechen.

Anweisungen in JenkinsGitHub Actions
environmentjobs.<job_id>.env
jobs.<job_id>.steps[*].env
optionsjobs.<job_id>.strategy
jobs.<job_id>.strategy.fail-fast
jobs.<job_id>.timeout-minutes
parametersinputs
outputs
triggerson
on.<event_name>.types
on.<push>.<branches|tags>
on.<pull_request>.<branches>
on.<push|pull_request>.paths
triggers { upstreamprojects() }jobs.<job_id>.needs
Cron-Syntax in Jenkinson.schedule
stagejobs.<job_id>
jobs.<job_id>.name
toolsSpezifikationen für GitHub-gehostete Runner
inputinputs
whenjobs.<job_id>.if

Sequenzielle „Stages“ (Phasen) verwenden

Parallele Verarbeitungvon Jobs

Jenkins kann Phasen (stages) und Schritte (steps) parallel ausführen. Im Gegensatz dazu führt GitHub Actions derzeit nur Aufträge parallel aus.

Jenkins ParallelGitHub Actions
paralleljobs.<job_id>.strategy.max-parallel

Matrix

Sowohl GitHub Actions als auch Jenkins ermöglicht die Verwendung einer Matrix, um verschiedene Systemkombinationen zu definieren.

JenkinsGitHub Actions
axisstrategy/matrix
context
stagessteps-context
excludesKeine

Schritte verwenden, um „Tasks“ (Aufgaben) auszuführen

Jenkins gruppiert Schritte (steps) in Phasen (stages). Jeder dieser Schritte kann unter anderem ein Skript, eine Funktion oder ein Befehl sein. In ähnlicher Weise verwendet GitHub Actions Aufträge (jobs), um bestimmte Gruppen von Schritten (steps) auszuführen.

JenkinsGitHub Actions
stepsjobs.<job_id>.steps

Beispiele für häufige Aufgaben

Auszuführende Pipeline mit cron planen

Jenkins-Pipeline mit cron

pipeline {
  agent any
  triggers {
    cron('H/15 * * * 1-5')
  }
}

GitHub Actions-Workflow mit cron

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

Umgebungsvariablen in einer Pipeline konfigurieren

Jenkins-Pipeline mit einer Umgebungsvariablen

pipeline {
  agent any
  environment {
    MAVEN_PATH = '/usr/local/maven'
  }
}

GitHub Actions-Workflow mit einer Umgebungsvariablen

jobs:
  maven-build:
    env:
      MAVEN_PATH: '/usr/local/maven'

Aus „Upstream“ (vorgelagerten) Projekten bauen

Jenkins-Pipeline, die aus einem Upstream-Projekt erstellt wird

pipeline {
  triggers {
    upstream(
      upstreamProjects: 'job1,job2',
      threshold: hudson.model.Result.SUCCESS
    )
  }
}

GitHub Actions-Workflow, der aus einem Upstream-Projekt erstellt wird

jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

Mit mehreren Betriebssystemen bauen

Jenkins-Pipeline, die mit mehreren Betriebssystemen erstellt wird

pipeline {
  agent none
  stages {
    stage('Run Tests') {
      matrix {
        axes {
          axis {
            name: 'PLATFORM'
            values: 'macos', 'linux'
          }
        }
        agent { label "${PLATFORM}" }
        stages {
          stage('test') {
            tools { nodejs "node-16" }
            steps {
              dir("scripts/myapp") {
                sh(script: "npm install -g bats")
                sh(script: "bats tests")
              }
            }
          }
        }
      }
    }
  }
}

GitHub Actions-Workflow, der mit mehreren Betriebssystemen erstellt wird

name: demo-workflow
on:
  push:
jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os: [macos-latest, ubuntu-latest]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 16
      - run: npm install -g bats
      - run: bats tests
        working-directory: ./scripts/myapp