This is a small tool and service for updating YAML files with image references, to simplify continuous deployment pipelines.
It updates a YAML file in a Git repository, and optionally opens a Pull Request.
$ ./image-hooks --help
Update YAML files in a Git service, with optional automated Pull Requests
Usage:
image-hooks [command]
Available Commands:
help Help about any command
http update repositories in response to image hooks
update update a repository configuration
Flags:
-h, --help help for image-hooks
Use "image-hooks [command] --help" for more information about a command.
There are two sub-commands, http
and update
.
http
provides a Webhook service, and update
will perform the same
functionality from the command-line.
This requires a AUTH_TOKEN
environment variable with a token.
$ ./image-hooks update --file-path service-a/deployment.yaml --image-repo quay.io/myorg/my-image --source-repo mysource/my-repo --new-image-url quay.io/myorg/my-image:v1.1.0 --update-key spec.template.spec.containers.0.image
This would update a file service-a/deployment.yaml
in a GitHub repo at mysource/my-repo
, changing the spec.template.spec.containers.0.image
key in the file to quay.io/myorg/my-image:v1.1.0
, the PR will indicate that this is an update from quay.io/myorg/my-image
.
If you need to access a private GitLab or GitHub installation, you can provide
the --api-endpoint
e.g.
$ ./image-hooks update --file-path service-a/deployment.yaml --image-repo quay.io/myorg/my-image --source-repo mysource/my-repo --new-image-url quay.io/myorg/my-image:v1.1.0 --update-key spec.template.spec.containers.0.image
For the HTTP service, you will likely need to adapt the deployment.
You can also opt to allow for insecure TLS access with --insecure
.
This is a micro-service for updating Git Repos when a hook is received indicating that a new image has been pushed from an image repository.
This currently supports receiving hooks from Docker and Quay.io.
Neither Docker Hub nor Quay.io provide a way for receivers to authenticate Webhooks, which makes this insecure, a malicious user could trigger the creation of pull requests in your git hosting service.
Please understand the risks of using this component.
This service uses a really simple configuration:
repositories:
- name: testing/repo-image
sourceRepo: my-org/my-project
sourceBranch: master
filePath: service-a/deployment.yaml
updateKey: spec.template.spec.containers.0.image
branchGenerateName: repo-imager-
This is a single repository configuration, Repo Push notifications from the
image testing/repo-image
, will trigger an update in the repo
my-org/my-project
.
The change will be based off the master
branch, and updating the file
service-a/deployment.yaml
.
Within that file, the spec.template.spec.containers.0.image
field will be replaced
with the incoming image.
A new branch will be created based on the branchGenerateName
field, which
would look something like repo-imager-kXzdf
.
If no value is provided for branchGenerateName
, then the sourceBranch
will
be updated directly, this means that if you use master
, then the token must
have access to push a change directly to master.
The tool reads a YAML definition, which in the provided Deployment
is mounted
in from a ConfigMap
.
$ kubectl create configmap image-hooks-config --from-file=config.yaml
The default deployment requires a secret to expose the GITHUB_TOKEN
to the
service.
$ export GITHUB_TOKEN=<insert github token>
$ kubectl create secret generic image-hooks-secret --from-literal=token=$GITHUB_TOKEN
A Kubernetes Deployment
is provided in ./deploy/deployment.yaml.
The service is not dependent on being executed within a Kubernetes cluster.
By default, this accepts hooks from Docker hub but the deployment can easily be changed to support Quay.io.
The --parser
command-line option chooses which of the supported (Quay, Docker)
hook formats to parse.
The Service exposes a Hook handler at /
on port 8080 that handles the
configured hook type.
A Dockerfile
is provided for building a container, but otherwise:
$ go build ./cmd/quay-hooks
$ go build ./...