CI/CD Pipeline Generator & Converter

About the CI/CD Pipeline Generator & Converter

Describe your project once — the stack (Node.js with npm, pnpm or Yarn; Python with pip, Poetry or uv; Java with Maven or Gradle; Go; Rust; .NET; PHP; Ruby; a Docker image; a static site), the jobs (lint, a test matrix over versions and operating systems, build with its artifacts, a container image, a deploy step), the triggers (pushes and pull requests with branch filters, tags, manual runs, a schedule) and the names of the secrets the deploy reads — and get the same pipeline as a GitHub Actions workflow (which Gitea and Forgejo Actions also run), .gitlab-ci.yml, bitbucket-pipelines.yml, azure-pipelines.yml, a SourceHut build manifest and Woodpecker CI workflows, each block with a comment that says what it does.

The files start secure: the GitHub token can only read the repository, third-party actions are pinned to the full commit SHA of their latest release (the version in a comment), checkout leaves no credentials behind, pull requests never run with your secrets, and secrets reach only the step that uses them. Convert turns a file you already have into another format where the ideas match — stages, needs, matrices, caches, artifacts, rules — and lists every construct that has no equivalent. Validate checks a file against the JSON Schema its format publishes, and GitHub Actions files also with the GitHub Actions Linter’s checks. Cost estimates the CI minutes a month on each service against its included minutes.

Everything runs in your browser; no file is uploaded. Without a pass the result is a free preview: the first lines of each file, every check count with the first problems, and the first rows of the estimate. The full files, the ZIP, copying and the full reports unlock with a Pro pass.

What each file does by default

• GitHub Actions: permissions: contents: read at the top, packages: write only for the image job, actions pinned to commit SHAs, persist-credentials: false on checkout, a concurrency group that cancels superseded runs except on the deploy branch, pull requests on pull_request (never pull_request_target).
• GitLab CI: workflow:rules that run merge request pipelines without a duplicate branch pipeline, caches inside the project folder keyed by the lock file, jobs that start as soon as what they need is done, and deployments that are never interrupted.
• Bitbucket Pipelines: each job defined once with a YAML anchor and reused by every section; a matrix becomes parallel steps.
• Azure Pipelines: the toolchain from Microsoft’s tool tasks, Cache@2 keyed by the lock file, a deployment job for the environment, and secret variables mapped into the one step that reads them.
• SourceHut: Alpine packages, the deploy guarded by GIT_REF, and command logging turned off before a secret is read (builds run with set -x).
• Woodpecker CI: one workflow per job, ordered with depends_on, secrets with from_secret.

In every format the container image is built on every run and pushed only on pushes to the deploy branch (without a deploy job, to the branches whose pushes start the pipeline) and on version tags when tags start it; pull requests and other branches only build it. A converted file keeps a step’s own variables (exported in front of its commands where a job is one script), and lists the expressions and runner variables of the old format that its scripts still use.

Gitea and Forgejo

Choose Gitea or Forgejo under GitHub-compatible host to write the workflow to .gitea/workflows/ or .forgejo/workflows/. Gitea fetches an action named without a server from github.com while its DEFAULT_ACTIONS_URL setting keeps its default (Gitea’s configuration reference). Forgejo resolves a short uses: against its own actions host, and Forgejo’s reference strongly recommends fully qualified URLs, so for Forgejo each action is written as https://github.com/owner/repo@<sha>. Runner labels in runs-on must match the labels your runners declare.

Where the minutes come from

The estimate uses each service’s published rules, and the included minutes are fields you can change: GitHub Actions billing (2,000 minutes a month on GitHub’s no-cost plans; standard GitHub-hosted runners cost nothing for public repositories) and runner pricing (each job rounded up to a whole minute); GitLab compute minutes (400 a month on GitLab’s no-cost tier, job time × the runner’s cost factor: small Linux 1, medium 2, large 3; 0.5 for public projects in the GitLab for Open Source program); Bitbucket pricing (50 build minutes on the no-cost plan, counted by runner size: a 5-minute step on a 2× runner counts as 10 minutes); Azure parallel jobs (for private projects one Microsoft-hosted job at a time, up to 60 minutes each and 1,800 minutes a month, for an organization with billing set up). SourceHut and Woodpecker have no monthly minutes: SourceHut asks for a paid account to submit builds (its billing FAQ), and Woodpecker runs on your own machines.

Schemas the files are checked against

GitHub workflows: the JSON Schema Store’s github-workflow schema and the GitHub Actions Linter’s checks. GitLab: the schema GitLab publishes for .gitlab-ci.yml. Azure Pipelines: Microsoft’s schema from its VS Code extension. Woodpecker: Woodpecker’s own schema. Bitbucket and SourceHut files are checked against rules written from Atlassian’s configuration reference and the build manifest reference.

The bundled GitLab, Azure Pipelines and Woodpecker schemas are copies with their descriptions removed (every validation rule unchanged), used under their licences: GitLab’s schema © GitLab Inc. under the MIT licence, Microsoft’s © Microsoft Corporation under the MIT licence, and Woodpecker’s © the Woodpecker Authors under the Apache License 2.0.

Limitations

• Only these six formats: Jenkinsfiles, CircleCI and Travis CI files are not read or written.
• Conversion covers what the formats share. Reusable workflows, includes and templates are not followed (convert each file on its own), and anything else that does not convert is listed with its line.
• GitLab, Bitbucket and Woodpecker keep schedules in their settings, not in the file; the setup notes say where to add them.
• The commands are sensible defaults for each stack; change them to your project’s own scripts.
• The minutes estimate is only as good as the job times and run counts you give it, and the services can change their plans.

Privacy

On this device: nothing is sent

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.