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: [email protected]
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="[email protected]"
MSYNC_ARGS="--pr --pr-labels=managed-update --force"
- concierge
With Docker on the command line:
$ docker run --rm -v "$PWD":/app vshn/concierge
In a Docker Compose file as a pseudo-service:
concierge:
image: vshn/concierge
volumes:
- .:/app
The 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_hosts
file 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_ARGS
define additional arguments to pass tomsync
(e.g.MSYNC_ARGS=--noop
,MSYNC_ARGS=MSYNC_ARGS: --pr
)GITLAB_TOKEN
orGITHUB_TOKEN
API 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_KEY
andSSH_KNOWN_HOSTS
to 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!