GitHub Actions Importer: migrating pipelines from seven CI platforms, and where its releases stopped

Seven source platforms, one conversion target

The GitHub Actions Importer helps you plan and automate the migration of pipelines to GitHub Actions from seven platforms: Azure DevOps, Bamboo, Bitbucket, CircleCI, GitLab, Jenkins and Travis CI.

The list is the interesting part of the design decision, because it defines the scope precisely. This is not a general pipeline translation tool that accepts any YAML dialect. Each supported platform has its own configuration model, its own way of expressing a job, a stage, a secret, a trigger and an artefact, and the importer is the component that knows how to read all seven of them and write GitHub Actions workflows.

The framing in the documentation is that it helps you plan, test and automate your migration. The three verbs matter. Planning is the read side, where the importer inspects your existing pipelines and tells you what it would generate. Testing is the write side in a scratch context, where you can see the produced workflow before it lands in a repository. Automating is running that over a whole estate rather than one pipeline at a time.

That last mode is the one that changes the economics. Migrating one Jenkins job to a GitHub Actions workflow is an afternoon of work for someone who knows both systems. Migrating several hundred jobs across seven platforms is a project, and that is the case this tool is for.

Support for the tool runs through GitHub support, and there is a separate labs repository with platform-specific learning paths that teach both the tool and how to approach migrations, which is a reasonable way to learn a conversion workflow that has more steps than a single command.

A container with a CLI extension in front of it

The distribution model is unusual and worth understanding before you install anything. GitHub Actions Importer is distributed as two things: a Docker container, and an extension to the official GitHub CLI that is used to interact with that container.

The extension is a thin front end. The real work happens inside the container, which means the extension is what you type and the container is what needs credentials, network access and a compatible environment. That arrangement is what lets the tool be updated without reinstalling the CLI extension, and it is also why the Docker prerequisites are stated as hard requirements rather than recommendations.

The three prerequisites are: the Docker CLI must be installed and running, the official GitHub CLI must be installed, and you must have credentials to authenticate with the GitHub Container Registry.

The extension installs with:

gh extension install github/gh-actions-importer

And the update path is a separate command, because the container image moves faster than the extension does:

gh actions-importer update

That split explains something about the repository's release history. The extension and the container have independent version cadences, and the extension is the piece that lives in your PATH. The repository also recommends pulling the image from the official GitHub Container Registry, and documents the escape hatch if you need a different one, by setting CONTAINER_REGISTRY in a .env.local file:

# .env.local
CONTAINER_REGISTRY=my-custom-registry.com

The stated reason to prefer the official registry is control over which version of the importer you get, which is a reasonable concern for a tool that reads your CI configuration.

Credentials for two systems at once

For the importer to do its job it has to talk to both ends of the migration, which means credentials for your existing CI system and for GitHub.

These are configured through environment variables or a .env.local file, and there is an interactive path, which is the friendliest way to set them up the first time:

$ gh actions-importer configure
? Enter value for 'GITHUB_ACCESS_TOKEN' (leave empty to skip):
...

The prompt is interactive, asks for each value in turn, and lets you skip a value by leaving it empty. That matters because the required set depends on the platform you are migrating from, and the documentation points to platform-specific documentation for the details of which variables to set.

The two-file approach, environment variables or .env.local, is worth thinking about. Environment variables suit a CI job that runs the importer inside a pipeline, where secrets come from the CI system itself. A .env.local file suits a developer running it on a workstation, and it keeps the credentials out of your shell history. A .gitignore entry is the important detail in that case, since a file holding a personal access token and the credentials for your old Jenkins server should not end up in a commit.

The GITHUB_ACCESS_TOKEN prompt also shows the shape of the privilege question. The token needs write access to create the workflows in the target repository, and it needs read access to the source platform. A migration tool that writes files into your repositories is a privileged tool, and the token scoping is where that privilege is granted.

Demos, a labs repository, and the roadmap

The documentation approach is unusually thorough for a tool of this kind, and it is worth knowing what is there before you start.

There are recorded demos of the importer performing migrations from five platforms: Azure DevOps, CircleCI, GitLab, Jenkins and Travis CI. Each is a video walkthrough of the actual tool rather than a scripted mock-up, which means you can see the shape of a real run before you commit a pipeline to it. Note that the demos cover five of the seven supported platforms, so Bamboo and Bitbucket have no recorded walkthrough.

The labs repository is the other half. It contains platform-specific learning paths that teach how to use the importer and how to approach migrations to GitHub Actions, which is a distinction worth making: the tool does the conversion, and the labs cover the decisions around it.

For planning, there is a public product roadmap on GitHub, so you can see what features are coming rather than only what exists today.

Feedback goes through GitHub Discussions with a form that separates feedback from feature requests, and the project also carries a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, a ThirdPartyNotices.txt and an ownership.yaml.

That last pair is worth a note for anyone using this in a company. The ThirdPartyNotices file is the record of what the tool bundles, and the ownership.yaml declares which team owns the code. Both are the sort of file that a procurement or legal review looks for, and their presence is a reasonable signal about how the project is run rather than a hobby.

The release history gap, and what it means for pinning

Here is the fact that deserves attention before anyone plans a migration around this tool.

The repository's recent releases are v1.3.6 from 2023-10-04, v1.3.5 from 2023-09-12 and v1.3.4 from 2023-07-27. The last push to the repository was on 2026-09-10. The repository is not archived.

So the source has been touched roughly three years after the last tagged release. That is a meaningful gap for a tool whose value is in its knowledge of the source and target platforms, because platform support changes: a new GitLab CI feature or a new Bitbucket Pipelines syntax can appear, and the importer needs to learn about it to keep converting correctly.

There are two reasonable readings of this. One is that the tool is in maintenance, the code is stable, and the tagged release is still the thing most people should use, which is a defensible position for a conversion utility where stability matters more than new features. The other is that the releases lag the work, and the images being pulled from the container registry are not necessarily the v1.3.6 sources.

The practical advice is to pin deliberately rather than to assume. Check which version the container registry is actually serving, and record it. For a migration that touches hundreds of workflows, the reproducibility of the tool that generated them is worth more than a newer build.

On licensing, the project is MIT licensed with a LICENSE file at the root and a .licenses directory, and the ThirdPartyNotices file records the licences of the dependencies that ship inside the container.

Editorial conclusion

GitHub Actions Importer fits an organisation consolidating several CI systems into GitHub Actions, where the volume of pipelines makes manual conversion the bottleneck and a machine-generated starting point is worth the review time. It is a poor fit for a single pipeline or two, where writing the workflow by hand is quicker, and a poor fit if you cannot run containers or the GitHub CLI in your environment, since both are hard prerequisites. Before adopting, check the version you would actually pull, because the published releases stop at v1.3.6 from 2023-10-04 even though the repository itself was pushed to on 2026-09-10, and configure the credentials for both your old CI system and GitHub before the first run.

Frequently asked questions

Official sources

1. github/gh-actions-importer on GitHub
2. Issues
3. License: MIT
4. README
5. Releases