Jenkinsfile to GitHub Actions Converter

Convert Jenkins Declarative and Scripted Pipelines to GitHub Actions workflows.

When to Use This Skill

• •User provides a Jenkinsfile and wants GitHub Actions equivalent
• •User asks to migrate from Jenkins to GitHub Actions
• •User mentions Jenkins pipeline conversion
• •User has CI/CD in Jenkins and wants to move to GHA

Quick Reference

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 used (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

When converting complex pipelines, ask:

1. •Shared libraries - "I see you're using my-lib. Do you have an equivalent reusable workflow?"
2. •Credentials - "This pipeline uses credentials 'deploy-key'. What secrets should I reference?"
3. •Triggers - "Jenkins uses pollSCM every 15 min. Should I convert to push-based triggers?"
4. •Approvals - "There's an input step. Use GitHub Environments with required reviewers?"
5. •Action mirrors - "Do you need internal action mirrors? What's your prefix?"
6. •Runners - "GitHub-hosted or self-hosted runners? What labels?"

3. Generate Workflow

Apply mappings from reference docs:

• •Concept Mappings - Core Jenkins → GHA concepts
• •Plugin Mappings - Jenkins plugins → GHA actions
• •Shared Libraries - Converting shared libs 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 using)
• •Any manual steps needed

Examples

• •Simple Pipelines - Basic build, test, deploy patterns
• •Complex Pipeline - Full CI/CD with parallel tests, Docker, K8s deployments

Key Patterns

Parallel Stages → Parallel Jobs

// Jenkins
parallel {
    stage('Unit') { steps { sh 'npm test:unit' } }
    stage('Lint') { steps { sh 'npm run lint' } }
}

# 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

// Jenkins
withCredentials([[$class: 'AmazonWebServicesCredentialsBinding', credentialsId: 'aws']]) {
    sh 'aws s3 ls'
}

# GitHub Actions - prefer OIDC
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

// Jenkins
input message: 'Deploy to prod?', submitter: 'release-team'

# GitHub Actions
jobs:
  deploy:
    environment: production  # Configure required reviewers in GitHub

Output Checklist

When generating a workflow, ensure:

• • SHA-pinned actions with version comments (e.g., @abc123 # v4.1.1)
• • timeout-minutes set on all jobs
• • concurrency group to prevent duplicate runs
• • Caching enabled for dependencies
• • Least-privilege permissions
• • Secrets listed in setup requirements
• • OIDC recommended over stored credentials