Jenkins Migration
Convert Jenkins Declarative and Scripted Pipelines to GitHub Actions workflows.
Official Resources
GitHub provides automated migration tooling:
- •GitHub Actions Importer -
gh actions-importerCLI for automated conversion - •Migration Guide - Official conceptual mapping
This skill provides detailed mappings for manual conversion and edge cases the automated tool misses.
Quick Reference
| Jenkins | GitHub Actions |
|---|---|
pipeline {} | .github/workflows/*.yml |
agent any | runs-on: ubuntu-latest |
stages {} | jobs: |
steps {} | steps: |
environment {} | env: |
when { branch 'main' } | if: github.ref == 'refs/heads/main' |
parallel {} | Multiple jobs (parallel by default) |
post { always {} } | if: always() |
input (approval) | environment: with reviewers |
See references/concept-mappings.md for complete mappings.
Conversion Workflow
1. Analyze the Jenkinsfile
Identify:
- •Pipeline type (Declarative vs Scripted)
- •Stages and their purposes
- •Build tools (Maven, Gradle, npm, etc.)
- •Jenkins plugins referenced
- •Environment variables and credentials
- •Triggers (cron, webhooks, SCM polling)
- •Post-build actions
- •Shared library usage (
@Library)
2. Ask Clarifying Questions
For complex pipelines:
- •Shared libraries - "I see
@Library('my-lib'). Do you have an equivalent reusable workflow?" - •Credentials - "This uses credentials 'deploy-key'. What secrets should I reference?"
- •Triggers - "Jenkins uses pollSCM. Convert to push-based triggers?"
- •Approvals - "There's an
inputstep. Use GitHub Environments with required reviewers?" - •Runners - "GitHub-hosted or self-hosted runners?"
3. Generate Workflow
Apply mappings from reference docs:
- •Concept Mappings - Core Jenkins → GHA concepts
- •Plugin Mappings - Jenkins plugins → GHA actions
- •Shared Libraries - Converting to reusable workflows
- •Enterprise Config - Action mirrors, self-hosted runners
- •Best Practices - SHA pinning, caching, security
4. Document Setup Requirements
Always list:
- •Secrets to configure
- •GitHub Environments to create
- •OIDC trust policies (if applicable)
- •Manual steps needed
Key Patterns
Parallel Stages → Parallel Jobs
groovy
// Jenkins
parallel {
stage('Unit') { steps { sh 'npm test:unit' } }
stage('Lint') { steps { sh 'npm run lint' } }
}
yaml
# GitHub Actions - jobs run in parallel by default
jobs:
unit:
runs-on: ubuntu-latest
steps:
- run: npm test:unit
lint:
runs-on: ubuntu-latest
steps:
- run: npm run lint
Credentials → Secrets + OIDC
groovy
// Jenkins
withCredentials([[$class: 'AmazonWebServicesCredentialsBinding', credentialsId: 'aws']]) {
sh 'aws s3 ls'
}
yaml
# GitHub Actions - prefer OIDC over stored secrets
permissions:
id-token: write
steps:
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
- run: aws s3 ls
Manual Approval → Environments
groovy
// Jenkins input message: 'Deploy to prod?', submitter: 'release-team'
yaml
# GitHub Actions - configure required reviewers in repo settings
jobs:
deploy:
environment: production
Output Checklist
When generating a workflow:
- • SHA-pinned actions with version comments (e.g.,
@abc123 # v4.1.1) - •
timeout-minutesset on all jobs - •
concurrencygroup to prevent duplicate runs - • Caching enabled for dependencies
- • Least-privilege
permissions - • Secrets listed in setup requirements
- • OIDC recommended over stored credentials
Examples
- •Simple Pipelines - Basic build, test, deploy
- •Complex Pipeline - Full CI/CD with parallel tests, Docker, K8s