Concierge is configuration management for your Git repositories driven by the CI service of your choice (GitLab CI, Bitbucket Pipelines, Travis CI, Circle CI -- you name it).
Concierge builds on ModuleSync
and loops over a number of ModuleSync configurations from a configs/ directory.
This allows you to bulk-manage a vast number of Git repositories from a single
configuration repository. The companion CLI concierge-cli further extends the automation possibilities.
This Docker image is ready for use with OpenShift and Kubernetes.
- Create a CI configuration file (see below for examples).
- Create a
configs/folder. - Add a
<repository-config>/folder inside of it, and populate it with a ModuleSync configuration. - Add more ModuleSync config folders inside
configs/for different repository setups. - Put everything under version control, and push it to your CI service.
From now on, for every change you make to one of your configuration setups, ModuleSync will clone the repositories in question, apply your changes, and commit and push them. Just as you did before, manually cloning and applying changes. Now reliably, without forgetting any repo, and in a matter of seconds rather than hours.
# FILE: .gitlab-ci.yml
---
concierge:
image: vshn/concierge
script: concierge
variables:
GIT_COMMITTER_NAME: Concierge by VSHN
GIT_COMMITTER_EMAIL: concierge@vshn.ch
MSYNC_ARGS: --pr --pr-labels=managed-update --force
when: manual# FILE: bitbucket-pipelines.yml
---
pipelines:
default:
- step:
name: Concierge
image: vshn/concierge
script:
- GIT_COMMITTER_NAME="Concierge by VSHN"
GIT_COMMITTER_EMAIL="concierge@vshn.ch"
MSYNC_ARGS="--pr --pr-labels=managed-update --force"
- conciergeWith Docker on the command line:
$ docker run --rm -v "$PWD":/app vshn/conciergeIn a Docker Compose file as a pseudo-service:
concierge:
image: vshn/concierge
volumes:
- .:/appThe Concierge image sports two main commands: concierge and msync
The ModuleSync msync command, which is called by the concierge script,
uses Git and SSH. You can configure both of them via environment variables.
SSH_PRIVATE_KEY(default: empty) ... the private key used to connect to your Git server and clone repositoriesSSH_KNOWN_HOSTS(default: empty) ... content for the~/.ssh/known_hostsfile to identify trusted hostsGIT_USER_NAME,GIT_USER_EMAIL... override Git user (otherwise derived from last commit)GIT_COMMIT_MESSAGE... override Git commit message (otherwise derived from last commit)MSYNC_ARGSdefine additional arguments to pass tomsync(e.g.MSYNC_ARGS=--noop,MSYNC_ARGS=MSYNC_ARGS: --pr)GITLAB_TOKENorGITHUB_TOKENAPI access token must be set for automatic MR/PR generation to work (see ModuleSync docs)
Other environment values can be set as of the official Git documentation, but be warned that Git (or ModuleSync) can be very stubborn and may behave counterintuitively.
- Add
SSH_PRIVATE_KEYandSSH_KNOWN_HOSTSto your repository project at Settings > CI/CD > Variables. See the GitLab CI docs on SSH keys for background information. - Add the corresponding SSH public key to Settings > Repository > Deploy Keys, enabling "Write access allowed", for all Git repositories you want to allow Concierge to manage.
Follow steps 1, 2, 3 from the Use SSH keys in Bitbucket Pipelines article in the Bitbucket documentation.
Consider activating branch protection for your main branch, required code reviews (merge requests) and manual triggers of merging into your target branch.
Ideally, you enforce this policy in a tool-driven fashion leveraging the API of your code repository. You should also perform code reviews and merging in bulk from the command line, with a tool like concierge-cli.
Please, open an issue in our issue tracker on GitHub for bugs or feature requests. Pull requests are always welcome!