Skip to main content
This guide shows how to audit a Jenkins instance using the GitHub Actions Importer. The audit will:
  • Discover jobs and pipelines on a Jenkins server.
  • Attempt to convert each pipeline into a GitHub Actions workflow (dry-run).
  • Produce per-job output files (converted YAML, metadata, Jenkinsfile, errors) and an overall migration summary.
  • Export a workflow_usage.csv to help estimate required Actions, secrets, and runners.
A blue-green gradient slide with the centered text "Perform an Audit of Jenkins." A small "© Copyright KodeKloud" appears in the bottom-left corner.

​
What the audit does

  • Enumerates jobs and pipelines on the configured Jenkins instance.
  • Converts pipelines to equivalent GitHub Actions workflows in dry-run mode when possible.
  • Writes output files per job: converted workflow YAML (if generated), config.json metadata, original Jenkinsfile (when available), error details (if any), and an overall audit_summary.md.
  • Creates workflow_usage.csv with detected actions, secrets, and runners to support migration planning.

​
Prerequisites — configure credentials

Before running the audit, configure authentication for both GitHub and Jenkins. The interactive gh actions-importer configure flow writes credentials to a local environment file. Example interactive flow (sensitive values redacted):
The command populates .env.local:
Tip: Keep your tokens secure and do not commit .env.local to source control.

​
Run the audit

Run the audit and point outputs to a directory (example: tmp/audit):
Example (truncated) log output from a run:
This example completed in ~29 seconds and produced multiple files under tmp/audit.

​
Inspect the generated directory

After the run, examine the output structure. Example tree output:

​
Audit summary and interpretation

Open tmp/audit/audit_summary.md for a human-readable report. It contains importer version, timestamp, counts, and a breakdown of discovered pipelines and conversion statuses. Sample high-level summary: Result definitions:
  • Successful: Fully converted pipeline constructs and steps.
  • Partially successful: Major constructs converted; some steps require manual fixes.
  • Unsupported: Pipeline types the importer doesn’t convert automatically (e.g., scripted pipelines).
  • Failed: Conversion aborted due to fatal errors (network, fetch failures).

​
Job types detected

The audit maps Jenkins job types to readable labels:

​
Build steps and actions summary

The audit aggregates known vs unknown build steps and suggests mapped GitHub Actions. Example of known vs unknown steps (excerpt): Known steps (automatically mapped):
  • sh: 12
  • publishHTML: 6
  • junit: 2
  • hudson.tasks.Shell: 1
Unknown steps (need manual handling): 10 (32%)
  • withDockerRegistry: 2
  • catchError: 2
  • retry: 2
  • dependencyCheckPublisher: 2
  • dependencyCheck: 2
Suggested Actions (example):
  • actions/checkout@v4.1.0: 15
  • run: 13
  • actions/upload-artifact@v4.1.0: 6
  • EnricoMi/publish-unit-test-result-action@v2.12.0: 2
Triggers detected:
  • Total triggers: 1
  • Known triggers: 1 (100%) — poll-based SCM detected (can be mapped to schedule or workflow_dispatch).
Environment variables (sample):
  • Total env vars: 8
    • Known: 2 (25%) — MONGO_URI: 2
    • Unknown: 6 (75%) — MONGO_PASSWORD, MONGO_USERNAME, MONGO_DB_CREDS

​
Manual tasks and self-hosted runners

Actions the importer cannot automate and that require manual work:
  • Provision and configure self-hosted GitHub runners if Jenkins agents/labels were used.
  • Recreate repository/organization secrets in GitHub (the importer redacts secrets).
  • Implement custom plugin integrations or functionality that lacks a direct GitHub Actions equivalent.
Example runner info extracted:

​
Files produced per job

The importer creates a directory per job with relevant artifacts. Use the generated YAML and config.json as the basis for manual edits and secret/re-runner setup. Table — example per-job outputs:

​
workflow_usage.csv

workflow_usage.csv lists detected Actions, secrets, and runners for converted pipelines — useful to plan which Actions to include and which runners or secrets to configure. Sample CSV excerpt:

​
Logs and troubleshooting

  • Detailed logs and redaction notices are under tmp/audit/log/.
  • For unsupported or failed pipelines, inspect error.txt inside the job directory to identify conversion failures and required manual remediation.

​
Next steps — migrate and validate

  1. Review generated YAMLs under each job directory and adapt steps, paths, or environment-specific settings.
  2. Recreate required secrets in GitHub repositories or organization secrets.
  3. Provision self-hosted runners if needed and map runner labels to jobs.
  4. Use gh actions-importer dry-run for individual job iterations if you want to test conversions interactively.
  5. Use workflow_usage.csv to stockpile required Actions and identify runner needs.
For more about GitHub Actions and runners, see:
The audit provides a migration plan that highlights what can be auto-converted and what requires manual work. Use the per-job config.json and generated YAML as the authoritative reference when migrating each pipeline.
Scripted Jenkins pipelines are often unsupported by the importer and will appear as unsupported/failed — they require manual migration. Also, the importer redacts secrets and cannot provision self-hosted runners; you must recreate those manually in GitHub.
That’s a summary of the audit process and how to interpret the generated artifacts. In subsequent lessons you can explore individual generated YAML files and run dry-run conversions for individual pipelines.

Watch Video