We recently ran into a couple issues when trying to automate our workflow with CircleCI.
- Management and use of API tokens for CircleCI build status checks…
There are two types of tokens in CircleCI: user tokens (full-access) and repo tokens (scoped from read-only to full). Adding new projects to our deployment system means creating new read-only keys for each repo. The deployment process then has to use the corresponding key for the given repo.
Managing API keys for each repo will become an administrative burden if we start to go down the microservice path. What’s really needed here is a ORG level API keys with customizable permissions. This would make tasks like key rotation significantly easier.
- Retrieving build status for a given commit (based on hash for a lightweight git-based deploy) …
When a new commit is made, CircleCI triggers a build. When checking for the deployability of a commit, we need to interrogate CircleCI to see if the most recent build for a commit hash is passing. While we can pull a list of all builds, it requires several calls for paginated requests to find older commits (like a rollback).
A full-blown solution would be to build a deployment API that can leverage CircleCI webhooks. Short of that we could post to a key-value store at the end of the build. Either solution requires additional infrastructure & a deployed app (unless using file-based S3 buckets).
It would be a nice feature for lightweight deployment processes (git based deploys) to interrogate the Circle API by branch & commit for the highest-numbered build associated. Once we have the build id, a 2nd call can retrieve the build status. Checking build history by branch works well enough, not for older builds (in the event of rollback).