2 posts tagged with "API"

Conversational analytics is taking off, with Looker customers rapidly adopting Conversational Analytics in Looker to let users query business data through natural language.

In a multi-instance setup (such as Dev, Stage, and Prod), promoting agents between environments requires synchronizing runtime metadata, prompt configurations, and golden queries across instances. While our GitHub Actions release workflow demonstrates a three-tier pipeline, the underlying migration script uses looker-cli and supports generic source and target endpoints across any number of environments.

TL;DR​

You can run the migration script directly using looker-cli and curl:

# 1. Log in to both instances
looker-cli session login \
  --host "$LOOKER_SOURCE_BASE_URL" \
  --client-id "$LOOKER_SOURCE_CLIENT_ID" \
  --client-secret "$LOOKER_SOURCE_CLIENT_SECRET"

looker-cli session login \
  --host "$LOOKER_TARGET_BASE_URL" \
  --client-id "$LOOKER_TARGET_CLIENT_ID" \
  --client-secret "$LOOKER_TARGET_CLIENT_SECRET"

# 2. Run the migration script
curl -fsSL https://raw.githubusercontent.com/lkrdev/multi-instance-cicd-demo/main/scripts/migrate_agents_cli.sh | \
  LOOKER_SOURCE_BASE_URL="$LOOKER_SOURCE_BASE_URL" \
  LOOKER_TARGET_BASE_URL="$LOOKER_TARGET_BASE_URL" \
  bash -s -- config/content_agents_whitelist.yaml

Think of an access token like a corporate security badge. You wouldn't stand in line at the front desk to print a new visitor pass every time you walk through an interior door. Instead, you simply swipe your active badge until it expires.

Similarly, when your scripts or API services call Looker, they shouldn't authenticate from scratch on every request. Repeatedly logging into the API or logging in as a user (/login/:user endpoint) not only adds unnecessary latency but also creates token bloat that can degrade server performance at scale.

A simple token cache solves this. By storing access tokens locally, you restore active sessions instantly. Because Looker binds workspace state (Production vs. Developer Mode) directly to the session token, a user can maintain simultaneous dev and production tokens. Reusing a token already pinned to Developer Mode avoids the network round-trip of switching workspaces on every command.

If you are ready to implement this, jump directly to the code samples.