Skip to main content
Use the migrate command to convert a Jenkins pipeline into an equivalent GitHub Actions workflow. The tool will create a pull request (PR) in your repository containing the generated workflow and any migration artifacts. This guide explains the command format, key options, example usage, how to review the generated PR, and what to do after merging.

​
Command overview

Run the following command to start a Jenkins → GitHub Actions migration: 
gh actions-importer migrate jenkins
Key options:
FlagPurposeExample
--target-urlFull URL of the GitHub repository where the workflow will be added.https://github.com/:owner/:repo
--source-urlURL of the Jenkins job to migrate.http://localhost:8080/job/ci-pipeline-poll-scm
--output-dirLocal directory for migration artifacts and logs.tmp/migrate
Replace placeholders with your actual repository and Jenkins job URLs.

​
Examples

Generic form: 
gh actions-importer migrate jenkins \
  --target-url https://github.com/:owner/:repo \
  --output-dir tmp/migrate \
  --source-url <your-jenkins-job-url>
Concrete example: 
gh actions-importer migrate jenkins \
  --target-url https://github.com/octo-org/octo-repo \
  --output-dir tmp/migrate \
  --source-url http://localhost:8080/job/ci-pipeline-poll-scm

​
Expected output

If the command completes successfully, it prints where logs were written and the PR URL. Example output: 
[2022-08-20 22:08:20] Logs: 'tmp/migrate/log/actions-importer-20220916-014033.log'
[2022-08-20 22:08:20] Pull request: 'https://github.com/sidd-harth-7/solar-system/pull/1'
Use the Logs: path to inspect detailed migration diagnostics and the generated artifacts.

​
Reviewing the generated pull request

  1. Open the PR URL printed by the command.
  2. Read the PR description carefully — it contains a “Manual steps” section listing items that must be completed before the workflow will run correctly (for example, required secrets or platform-specific build tools).
  3. Inspect the files changed. Typically the new workflow file(s) appear under .github/workflows/. Confirm workflows, job steps, environment variables, and referenced secrets match your Jenkins pipeline’s intent.
  4. Make any manual edits directly in the PR if needed.
Example “Manual steps” section output: 
ci-pipeline-poll-scm

Ensure secret is available: ${{ secrets.mongo_db_password }}
Ensure build tool is available: nodejs
Create any required secrets at the repository or organization level before you merge the PR. Without those secrets, the workflow may fail when it runs.
Never commit plaintext credentials or secrets into the repository. Use GitHub repository or organization secrets for sensitive values referenced by the workflow.

​
What else to check in the PR

  • Files changed: confirm the workflow YAML(s) are added under .github/workflows/.
  • Steps: verify the sequence, build/install steps, and any scripts align with your Jenkins pipeline.
  • Environment and secrets: ensure env: and secrets: usage matches available secrets, or note which secrets must be created.
  • Runners and tool availability: check if the workflow expects specific runner labels or preinstalled tools (e.g., node, docker, kubectl) and update accordingly.

​
Merging and running the workflow

  1. After you finish reviewing the PR and have created any required secrets, merge the pull request to add the workflow to your repository.
  2. Once merged, go to the repository’s Actions tab to view workflow runs and logs.
  3. Inspect the run details and the workflow job graph to validate that the migrated pipeline behaves as expected. If jobs fail, use the logs saved in the PR artifacts or the --output-dir logs for deeper debugging.
A slide titled "PR review" showing a numbered 1–4 checklist for reviewing, viewing, merging, and running a pull request. On the right is a screenshot of a GitHub Actions run summary with job statuses and a workflow graph.
You can inspect logs and the job execution graph from the Actions tab to verify your migrated Jenkins pipelines are running as expected.

Watch Video