Diese Version von GitHub Enterprise wurde eingestellt am 2021-09-23. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für eine bessere Leistung, verbesserte Sicherheit und neue Features nimm ein Upgrade auf die neueste Version von GitHub Enterprise vor. Wende Dich an den GitHub Enterprise-Support, um Hilfe beim 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.

Note: GitHub Actions was available for GitHub Enterprise Server 2.22 as a limited beta. The beta has ended. GitHub Actions is now generally available in GitHub Enterprise Server 3.0 or later. For more information, see the GitHub Enterprise Server 3.0 release notes.


Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the 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 Workflow-Dateien in GitHub Actions ähnlich sind.
  • Jenkins verwendet „Stages“ (Phasen), um eine Gruppe von Schritten auszuführen, während GitHub Actions Jobs verwenden, um einen oder mehrere Schritte oder einzelne Befehle zu gruppieren.
  • Jenkins und GitHub Actions unterstützen Container-basierte Builds. Weitere Informationen finden Sie unter „Eine Docker-Container-Aktion erstellen“.
  • Schritte oder Aufgaben können wiederverwendet und in der Community gemeinsam genutzt werden.

Weitere Informationen findest Du unter „Kernkonzepte für GitHub Actions“.

Wesentliche 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 „Workflow-Syntax für GitHub-Aktionen."
  • 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 selbst-gehosteten Runnnern.

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.

Similarly, GitHub Actions can send jobs to GitHub-hosted or self-hosted runners, and you can use labels to classify runners according to various attributes. For more information, see "Understanding GitHub Actions" and "About self-hosted runners."

Sektionen verwenden, um Pipelines zu organisieren

Jenkins teilt seine Deklarative Pipelines in mehrere Sektionen auf. Similarly, GitHub Actions organizes its workflows into separate sections. 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
Beitrag
stagesjobs
stepsjobs.<job_id>.steps

Anweisungen verwenden

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|pull_request>.<branches|tags>
on.<push|pull_request>.paths
triggers { upstreamprojects() }jobs.<job_id>.needs
Cron-Syntax in Jenkinson.schedule
Phasejobs.<job_id>
jobs.<job_id>.name
tools
Specifications for GitHub-hosted runners
inputinputs
whenjobs.<job_id>.if

Sequenzielle „Stages“ (Phasen) verwenden

Parallele Verarbeitungvon Jobs

Jenkins kann die Phasen und Schritte parallel ausführen, wohingegen GitHub Actions derzeit nur Jobs parallel ausführen.

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

Build-Matrix

Sowohl GitHub Actions als auch Jenkins lassen Dich eine Build-Matrix verwenden, um verschiedene Systemkombinationen zu definieren.

JenkinsGitHub Actions
axisstrategy/matrix
context
stagessteps-context
excludes

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

Jenkins gruppiert „Steps“ (Schritte) zusammen in „Stages“ (Phasen). Jeder dieser Schritte kann unter anderem ein Skript, eine Funktion oder ein Befehl sein. In ähnlicher Weise verwenden GitHub Actions Jobs, um bestimmte Gruppen von Schritten auszuführen.

Jenkins-SchritteGitHub Actions
scriptjobs.<job_id>.steps

Beispiele für häufige Aufgaben

Zeitplanung einer Pipeline mit cron

Jenkins-Pipeline GitHub Actions-Workflow
pipeline {
  agent any
  triggers {
    cron('H/15 * * * 1-5')
  }
}
on:
  schedule:
    - cron: '*/15 * * * 1-5'

Umgebungsvariablen in einer Pipeline konfigurieren

Jenkins-Pipeline GitHub Actions-Workflow
pipeline {
  agent any
  environment {
    MAVEN_PATH = '/usr/local/maven'
  }
}
jobs:
  maven-build:
    env:
      MAVEN_PATH: '/usr/local/maven'

Aus „Upstream“ (vorgelagerten) Projekten bauen

Jenkins-Pipeline GitHub Actions-Workflow
pipeline {
  triggers {
    upstream(
      upstreamProjects: 'job1,job2',
      threshold: hudson.model.Result.SUCCESS
    )
  }
}
jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

Mit mehreren Betriebssystemen bauen

Jenkins-Pipeline GitHub Actions-Workflow
pipeline {
  agent none
  stages {
    stage('Run Tests') {
      matrix {
        axes {
          axis {
            name: 'PLATFORM'
            values: 'macos', 'linux'
          }
        }
        agent { label "${PLATFORM}" }
        stages {
          stage('test') {
            tools { nodejs "node-12" }
            steps {
              dir("scripts/myapp") {
                sh(script: "npm install -g bats")
                sh(script: "bats tests")
              }
            }
          }
        }
      }
    }
  }
}
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@v2
      - uses: actions/setup-node@v2
        with:
          node-version: 12
      - run: npm install -g bats
      - run: bats tests
        working-directory: scripts/myapp