What is jenkinsfile-to-gha?

This Claude skill automates the complex process of migrating CI/CD pipelines by converting Jenkinsfiles (both Declarative and Scripted) into optimized GitHub Actions workflows. It intelligently maps Jenkins concepts—including agents, stages, environment variables, and credentials—to their GitHub Actions equivalents, ensuring a seamless transition while adhering to modern DevOps best practices such as OIDC authentication and SHA-pinned actions.

When should I use jenkinsfile-to-gha?

jenkinsfile-to-gha is useful in the following scenarios: • Legacy Migration: Streamlining the transition of enterprise CI/CD infrastructure from Jenkins to GitHub Actions to consolidate the developer toolchain. • Pipeline Modernization: Converting verbose Jenkins scripted pipelines into clean, maintainable, and YAML-based GitHub Actions workflow files. • Security Hardening: Replacing Jenkins credential bindings with secure GitHub Actions secrets and OIDC-based authentication for cloud providers like AWS. • Workflow Optimization: Mapping Jenkins parallel stages and manual approval gates to efficient GitHub Actions job structures and environment-based deployment rules.

name	jenkinsfile-to-gha
description	Convert Jenkins pipelines (Jenkinsfiles) to GitHub Actions workflows. Use when migrating CI/CD from Jenkins to GitHub Actions, or when user provides a Jenkinsfile and wants a GHA workflow.
license	MIT
compatibility	Works with Claude Code and similar agents. No external tools required.
author	kenny
version	"2.0"

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

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 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:

Shared libraries - "I see you're using my-lib. Do you have an equivalent reusable workflow?"
Credentials - "This pipeline uses credentials 'deploy-key'. What secrets should I reference?"
Triggers - "Jenkins uses pollSCM every 15 min. Should I convert to push-based triggers?"
Approvals - "There's an input step. Use GitHub Environments with required reviewers?"
Action mirrors - "Do you need internal action mirrors? What's your prefix?"
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

jenkinsfile-to-gha

When & Why to Use This Skill

Use Cases