Handle Container Image "push" events from outside of TreeScale

Sometimes you need an integration between services and most of the Container CI, CD or Infrastructure environments expect to receive an HTTP request with the data of the container "push" event in order to trigger an action to pull a new container image or do something else. One of the best examples is Github Actions or Jenkins, where they expect to receive an HTTP Post request (or you can configure them) to trigger a new CI/CD pipeline to run your tests inside newly pushed container or just deploy a new version to Kubernetes production.

Setting Webhook

For better customisability at TreeScale we have an ability to set your WebHook URL for each repository individually. It is inside a Repository settings page and setting it as easy as juts typing a Webhook endpoint URL there. It has to be a valid URL, otherwise our system will start ignoring over time when it will fail requests few times in a row.

Individual Repository -> Settings page

JSON Payload

External integrated service should expect to receive an HTTP/S POST request with JSON body and some extra headers to identify request. You can also provide a URL query parameters to pass a token to your integrated service if you need to be sure only TreeScale can send an HTTP request to a given url.

User-Agent: TreeScale.com WebHook Handler
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
x-treescale-webhook: <username>/<repository>:<tag>
Content-Length: <size of JSON payload>
Content-Type: application/json

JSON Body is not customisable the the moment, but it could be over time if there is a real need for that.

"image": "repo.treescale.com/<username>/<repository>:<tag>",
"image_size": <pushed image size>,
"layers": [<pushed image layers>],
"repository": "repo.treescale.com/<username>/<repository>",
"repository_size": <repository size>,
"event": "push",
"timestamp": <ISO formatted time of the request>

Final Notes

It is important to know that our Webhook service sends a request asynchronously, which means that if you make a docker push it might take a few seconds to trigger a Webhook operation. That's because we want to make sure to not overload an integrated service with a blast of HTTP requests, so we batch them.