Skip to main content

Von Jenkins zu -Aktionen migrieren

Hinweis

Auf gehostete Runner werden aktuell nicht auf Enterprise Server unterstützt. Weitere Informationen zur geplanten zukünftigen Unterstützung findest Du in der public roadmap.

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

  • Jenkins erstellt Workflows mit deklarativen Pipelines, die den Workflowdateien in Actions ähneln.
  • Jenkins verwendet Phasen, um eine Reihe von Schritten auszuführen, während Actions Aufträge verwendet, um Schritte oder einzelne Befehle zu gruppieren.
  • Jenkins und Actions unterstützen Container-basierte Builds. Weitere Informationen finden Sie 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 finden Sie unter Grundlegendes zu Actions.

  • Jenkins hat zwei Arten von Syntax zur Erzeugung von Pipelines: Deklarative Pipeline und „Scripted“ (Skript-basierte) Pipeline. Actions verwendet YAML, um Workflows und Konfigurationsdateien zu erstellen. Weitere Informationen finden Sie unter Workflowsyntax für Actions.
  • Die Deployments von Jenkins ist üblicherweise selbst-gehosted, wobei die Benutzer die Server in ihren eigenen Rechenzentren betreuen. 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.

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 Actions Aufträge an von 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 Actions und Informationen zu selbstgehosteten Runnern.

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

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

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 Actions entsprechen.

Anweisungen in JenkinsActions
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 -gehostete Runner
inputinputs
whenjobs.<job_id>.if

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

Jenkins ParallelActions
paralleljobs.<job_id>.strategy.max-parallel

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

JenkinsActions
axisstrategy/matrix
context
stagessteps-context
excludesKeine

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 Actions Aufträge (jobs), um bestimmte Gruppen von Schritten (steps) auszuführen.

JenkinsActions
stepsjobs.<job_id>.steps

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

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

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

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

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

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

pipeline {
  agent none
  stages {
    stage('Run Tests') {
      matrix {
        axes {
          axis {
            name: 'PLATFORM'
            values: 'macos', 'linux'
          }
        }
        agent { label "${PLATFORM}" }
        stages {
          stage('test') {
            tools { nodejs "node-20" }
            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@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install -g bats
      - run: bats tests
        working-directory: ./scripts/myapp