Skip to main content

Deploying for Continuous Integration

Once you've set up Spectacles locally and run some validations, you may want to deploy Spectacles in your continuous integration (CI) environment so you can test your team's code or pull requests.

tip

Because of the relationship between Looker users and Git branches, concurrent runs in CI can cause flaky results and unexpected Spectacles failures. That's why we built a hosted Spectacles application to manage concurrency and provide a seamless web interface.

Keep reading if you'd like to understand the problem better.

The problem of concurrency​

During a validation, Spectacles authenticates to the Looker API with an API key that you provide. Each API key corresponds to a single Looker user, which Spectacles uses to checkout branches and run queries and data tests.

In Looker, a single user can only be on one branch at a time. This creates a problem for concurrent Spectacles validations. Here's an example:

Example

Josh and Dylan are teammates working on the same Looker project. Let's assume...

  • They've set up Spectacles to run in CircleCI after each GitHub pull request (PR).
  • They've also set up a dedicated Spectacles Looker user called Spectacles Bot.

Here's a series of events that would cause a flaky result due to concurrency:

  1. Josh finishes some development on a view called orders, so he opens a PR from his dev branch, dev-josh into master. CircleCI triggers a Spectacles SQL validation—Spectacles authenticates as Spectacles Bot, checks out dev-josh, and begins running test queries.

  2. Meanwhile, Dylan finishes some development of his own on orders and opens a PR from his dev branch dev-dylan into master. This causes CircleCI to kick off a new Spectacles SQL validation.

Since Spectacles is configured with a single user (Spectacles Bot) in CircleCI, Dylan's validation will check out Dylan's branch dev-dylan in the middle of Josh's validation, causing any remaining queries in Josh's validation to run on the wrong branch!