Cross-platform GitOps CLI built in Rust for managing organization repositories across GitHub, Azure DevOps, and GitLab.
This project is a container-first CLI for repository governance and maintenance at scale. The goal is to give you a single tool that can scaffold repositories, audit standards, sync shared files, generate catalogs, and align metadata across multiple source-control platforms.
Managing an organization with many repositories usually leads to repeated manual work:
- keeping repo metadata aligned
- copying workflows and templates between repos
- auditing descriptions, topics, and licensing
- scaffolding new repositories from a standard template
- generating a reusable catalog of projects
devopster is intended to centralize that work behind one CLI and one config file.
The repository now includes:
- a Rust CLI package with the
devopsterbinary - a command tree for
init,repo,catalog,topics, andstats - a provider abstraction for GitHub, Azure DevOps, and GitLab
- YAML configuration loading through
devopster-config.yaml - a dev container and Docker-based workflow so the host machine does not need Rust installed
- a CI workflow that builds and tests through containers
This project is designed to run inside a container. The only required tool on your host machine is make, everything else including Docker is installed automatically by make setup.
| Tool | Where | How |
|---|---|---|
| Homebrew | macOS only, if missing | Official install script |
| Docker Desktop | macOS | brew install --cask docker |
| Docker Engine | Debian/Ubuntu | Official apt repository |
gh, az, glab, Rust, devopster |
Inside the container | Dockerfile |
On macOS, after Docker Desktop is installed for the first time you need to start it from Applications, then re-run
make setup.
- Clone the repository.
- Open it in VS Code.
- Reopen the folder in the Dev Container.
- The post-create step runs
make setupautomatically.
# First time on a new machine -- installs Docker if needed, builds the image,
# and drops you into the container shell where devopster is ready to use:
make setup
# Inside the container:
devopster init
devopster repo listTo reopen the container shell after exiting, run
make setupagain ormake container-run.
After make setup the devopster binary is on your $PATH and these commands work directly:
| Command | Purpose |
|---|---|
devopster init |
Create devopster-config.yaml and interactively sign in to a provider |
devopster init --no-login |
Create devopster-config.yaml only, skip the sign-in prompt |
devopster login <github|azure-devops|gitlab> |
Sign in to that provider via browser, uses gh, az, or glab CLI |
devopster login all |
Sign in to all three providers sequentially |
devopster login status |
Show authentication status for all providers |
devopster login logout <provider> |
Remove stored credentials for a provider |
devopster repo list |
List all repositories in the configured organization |
devopster repo list --topic rust |
Filter repositories by topic |
devopster repo audit |
Audit repos for missing description, topics, license, and default branch |
devopster repo scaffold --name <name> --template <template> |
Create a new repository from a template defined in config |
devopster repo sync |
Push files from .github/ to all repositories |
devopster catalog generate |
Export a JSON catalog of all repositories |
devopster topics align |
Add missing template topics to every matching repository |
devopster stats |
Print a summary: provider, org, and total repository count |
# 1. build the image and install devopster
make setup
# 2. init: creates devopster-config.yaml and asks which provider to sign in to
devopster init
# 3. run any command
devopster repo list
devopster repo audit
devopster repo scaffold --name sample-repo --template azure-overview
devopster catalog generate
devopster topics align
devopster statsTo skip the sign-in prompt:
devopster init --no-login
Start from the example file:
cp devopster-config.example.yaml devopster-config.yamlThen set the provider and token environment variables you want to use.
The current scaffold is intentionally focused on the architecture and containerized workflow. The next implementation steps are:
- wire real provider SDKs and REST clients
- add repository creation and file sync logic
- implement policy-based auditing
- render templates for new repository scaffolding
- generate machine-readable and web-friendly org catalogs