Installation und Konfiguration von Looker CI/CD

Auf dieser Seite wird erläutert, wie Sie die erforderlichen Komponenten installieren und konfigurieren, um einen CI/CD-Workflow in Looker zu implementieren.

Diese Anweisungen basieren auf einem dreistufigen System, das aus Entwicklung, QA und Produktion besteht. Die gleichen Prinzipien können jedoch auch auf ein zwei- oder vierstufiges System angewendet werden.

In dieser Anleitung wird auch davon ausgegangen, dass Sie GitHub als Git-Anbieter verwenden. Sie können andere Git-Anbieter verwenden, um einen CI/CD-Workflow zu erstellen. Sie müssen jedoch die entsprechenden Kenntnisse haben, um diese Anleitung für Ihren Anbieter zu ändern.

Folgen Sie der Anleitung in dem Abschnitt, der für Sie relevant ist:

Vorbereitung

Linux-Umgebung

Dazu werden Tools namens Gazer und Spectacles verwendet, die für Unix-ähnliche Betriebssysteme entwickelt wurden. Jeder LookML-Entwickler muss Zugriff auf die Befehlszeile in einer Linux- oder macOS-Umgebung haben, in der Sie Ihren CI/CD-Workflow ausführen möchten.

Wenn Sie Windows verwenden, können Sie Gazer und Spectacles im Windows Subsystem For Linux (WSL) von Microsoft verwenden. Mit WSL können Sie verschiedene Linux-Varianten ausführen. Wenn Sie kein bevorzugtes Linux-Betriebssystem haben, ist die neueste Version von Ubuntu Linux aufgrund ihrer breiten Unterstützung eine gute Wahl.

Diese Anleitung enthält Beispiele für Linux-Systeme. Möglicherweise müssen Sie sie ändern, wenn Sie macOS oder WSL verwenden.

Eine Looker-Instanz pro Stufe

Zum Aktivieren dieser Konfiguration benötigen Sie eine Looker-Instanz für jede Stufe Ihres Systems. Ein System mit einer Entwicklungsphase, einer QA-Phase und einer Produktionsphase benötigt beispielsweise drei separate Instanzen. Die Instanzen können von Google oder vom Kunden gehostet werden.

Identische Verbindungsnamen

Datenbankverbindungen sollten in jeder Looker-Instanz denselben Namen haben, unabhängig von ihrer Stufe. Eine sales-Verbindung sollte beispielsweise in allen Instanzen diesen Namen haben und nicht sales_dev oder sales_qa.

Die Verbindungen können auf dieselbe Datenbank oder verschiedene Datenbanken verweisen. Wenn sie jedoch auf dieselbe Datenbank verweisen, sollten sie unterschiedliche Scratch-Schemas definiert haben, damit persistente abgeleitete Tabellen in der Entwicklungs- oder QA-Instanz die Produktion nicht beeinträchtigen.

Wenn beispielsweise für alle drei Instanzen dieselbe Datenbank verwendet wird, können diese so konfiguriert werden:

Produktion QA Entwicklung
Verbindungsname sales sales sales
Datenbank sales_db sales_db sales_db
Scratch-Schema prod_sales_scratch qa_sales_scratch dev_sales_scratch

Wenn für alle drei Instanzen eine eindeutige Datenbank verwendet wird, können diese auch wie folgt konfiguriert werden:

Produktion QA Entwicklung
Verbindungsname sales sales sales
Datenbank sales_db_prod sales_db_qa sales_db_dev
Scratch-Schema sales_scratch sales_scratch sales_scratch

Git-Repository

Für jedes Projekt wird auf allen drei Ebenen ein einzelnes Git-Repository verwendet. Die Entwicklungsinstanz verfolgt den Zweig main, während die Instanzen für QA und Produktion in der Regel auf Git-Tags verweisen. Dies wird später ausführlicher beschrieben.

Schritte für die Ersteinrichtung

Die Schritte in diesem Abschnitt müssen nur einmal von einem Nutzer mit Looker-Administratorberechtigungen und Administratorberechtigungen für den Git-Anbieter ausgeführt werden.

Git-Anmeldedaten

Die Linux-Umgebung jedes Entwicklers muss eine Verbindung zu demselben Repository herstellen, das Sie zur Verwaltung Ihres LookML-Codes verwenden. Dies ist wahrscheinlich ein externes Repository, das in einem Dienst wie GitHub gehostet wird. Sie benötigen ein Konto bei diesem Dienst mit den entsprechenden Anmeldedaten, um das Repository zu konfigurieren. Mit dem Konto können Sie einen SSH-Schlüssel einrichten, damit Ihre Linux-Umgebung automatisch eine Verbindung zu diesem Dienst herstellen kann.

Für GitHub folgen Sie der Anleitung unter Neuen SSH-Schlüssel zum GitHub-Konto hinzufügen.

Git-Server-Repository erstellen und konfigurieren

Damit der CI/CD-Workflow funktioniert, muss LookML in einem Git-Repository gespeichert und mit einem Looker-Projekt verbunden werden. In den Projekteinstellungen muss Git Production Branch Name auf main und Enable Advanced Deploy Mode aktiviert sein.

Wenn die folgenden Schritte noch nicht ausgeführt wurden, folgen Sie dieser Anleitung für GitHub:

Neues Repository erstellen

  1. Klicken Sie in der GitHub-Benutzeroberfläche oben rechts auf die Schaltfläche + und wählen Sie dann Neues Repository aus.
  2. Wählen Sie den Inhaber aus (wahrscheinlich Ihre Organisation) und geben Sie eine REPOSITORY_NAME ein.
  3. Wählen Sie aus, ob das Repository öffentlich oder privat sein soll (private Repositories erfordern ein kostenpflichtiges GitHub-Abo), und klicken Sie das Kästchen an, um es mit einer README-Datei zu initialisieren.
  4. Klicken Sie auf die Schaltfläche Repository erstellen.
  5. Klicken Sie auf die grüne Schaltfläche <> Code und kopieren Sie die SSH-URL. Sie sieht in etwa so aus: git@github.com:org_name/REPOSITORY_NAME.git.
  6. Erstellen Sie ein neues Projekt in Looker.
  7. Wechseln Sie in den Entwicklungsmodus, wählen Sie in der linken Seitenleiste das Element für die Projekteinstellungen und dann Git konfigurieren aus.
  8. Fügen Sie die Repository-URL ein (in diesem Beispiel git@github.com:org_name/REPOSITORY_NAME.git) und wählen Sie Weiter aus.
  9. Kopieren Sie den Bereitstellungsschlüssel und kehren Sie zur GitHub-UI für dieses Repository zurück.
  10. Wählen Sie Einstellungen und dann Schlüssel bereitstellen aus.
  11. Klicken Sie auf die Schaltfläche Bereitstellungsschlüssel hinzufügen und fügen Sie den Bereitstellungsschlüssel in das Feld Schlüssel ein.
  12. Fügen Sie einen Titel wie z. B. Looker-REPOSITORY_NAME hinzu, aktivieren Sie das Kontrollkästchen Schreibzugriff zulassen und klicken Sie auf die Schaltfläche Schlüssel hinzufügen.
  13. Kehren Sie zu Looker zurück und wählen Sie Test and Finalize Setup (Einrichtung testen und abschließen) aus.
  14. Wählen Sie in der linken Seitenleiste noch einmal die Projekteinstellungen aus. Ändern Sie den Git-Produktionszweignamen in main.
  15. Wählen Sie Erweiterten Bereitstellungsmodus aktivieren und dann Projektkonfiguration speichern aus.

Unterhalb des Symbols für die Projekteinstellungen auf der linken Seite sollte ein Bereitstellungssymbol für Deployment Manager angezeigt werden.

Vorhandenes Repository verwenden

  1. Wechseln Sie zum GitHub-Repository, in dem Ihr LookML-Code gespeichert ist.
  2. Klicken Sie auf die grüne Schaltfläche <> Code und kopieren Sie die SSH-URL. Sie sieht in etwa so aus: git@github.com:org_name/REPOSITORY_NAME.git.
  3. Erstellen Sie ein neues Projekt in Looker.
  4. Wechseln Sie in den Entwicklungsmodus, wählen Sie in der linken Seitenleiste das Element für die Projekteinstellungen aus und klicken Sie dann auf Git konfigurieren.
  5. Fügen Sie die Repository-URL ein (in diesem Beispiel git@github.com:org_name/REPOSITORY_NAME.git) und wählen Sie Weiter aus.
  6. Kopieren Sie den Bereitstellungsschlüssel und kehren Sie zur GitHub-UI für dieses Repository zurück.
  7. Wählen Sie Einstellungen und dann Schlüssel bereitstellen aus.
  8. Klicken Sie auf die Schaltfläche Bereitstellungsschlüssel hinzufügen und fügen Sie den Bereitstellungsschlüssel in das Feld Schlüssel ein.
  9. Fügen Sie einen Titel wie z. B. Looker-REPOSITORY_NAME hinzu, aktivieren Sie das Kontrollkästchen Schreibzugriff zulassen und klicken Sie auf die Schaltfläche Schlüssel hinzufügen.
  10. Kehren Sie zu Looker zurück und wählen Sie Test and Finalize Setup (Einrichtung testen und abschließen) aus.
  11. Wählen Sie in der linken Seitenleiste noch einmal die Projekteinstellungen aus. Ändern Sie den Git-Produktionszweignamen in main.
  12. Wählen Sie Erweiterten Bereitstellungsmodus aktivieren und dann Projektkonfiguration speichern aus.

Unterhalb des Symbols für die Projekteinstellungen auf der linken Seite sollte ein Bereitstellungssymbol für Deployment Manager angezeigt werden.

GitHub-Aktionen erstellen

Es ist hilfreich, mehrere GitHub-Aktionen zu erstellen, damit bei jeder LookML-Änderung automatisch verschiedene Prüfungen durchgeführt werden. Wenn Sie diese Aktionen hinzufügen möchten, müssen Sie Änderungen an Ihrem Git-Repository in Ihrer Linux-Umgebung vornehmen können. Wenn diese Option noch nicht verfügbar ist, folgen Sie der Anleitung unter Git konfigurieren.

Rufen Sie zum Hinzufügen der GitHub-Aktionen das Verzeichnis Ihres Repositorys in der Linux-Umgebung auf und fügen Sie das Unterverzeichnis .github/workflows hinzu. Nach der Einrichtung können diese Aktionen manuell über die Seite Aktionen der GitHub-Benutzeroberfläche ausgeführt werden.

Look-At-Me-Sideways (LAMS)

LAMS ist ein Open-Source-Linter, der Ihren LookML-Code auf Fehler und unzulässige Praktiken prüft. Fügen Sie dem Verzeichnis .github/workflows eine Datei mit dem Namen lams.yml und folgendem Inhalt hinzu:

name: LAMS

on:
  pull_request:
    branches: [ main ]
  push:
  workflow_dispatch:

jobs:
  lams_job:
    runs-on: ubuntu-latest
    name: LAMS LookML Linter Job
    steps:
    - name: Checkout your LookML
      uses: actions/checkout@v1
    - name: Setup Node
      uses: actions/setup-node@v1
      with:
        node-version: '16.x'
    - name: Install LAMS
      run: npm install -g @looker/look-at-me-sideways@3
    - name: Run LAMS
      run: lams --reporting=no

Jedes Mal, wenn ein Commit an GitHub übertragen oder eine Pull-Anfrage geöffnet wird, um Code mit dem Zweig main zusammenzuführen, wird LAMS ausgeführt.

Bitte freigeben

Release bitte ist ein Open-Source-Tool, das Releases automatisch mit den richtigen Versionsnummern kennzeichnet.

Fügen Sie dem Verzeichnis .github/workflows eine Datei mit dem Namen release-please.yml und folgendem Inhalt hinzu:

name: release-please

on:
  push:
    branches:
      - main
  workflow_dispatch:

permissions:
  contents: write
  pull-requests: write

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: google-github-actions/release-please-action@v3
        with:
          release-type: simple
          package-name: sales_project

Herkömmliche Commits

Diese GitHub-Aktion sorgt dafür, dass eine Pull-Anfrage mit einem Titel geöffnet wird, der dem Conventional Commit-Standard entspricht.

Fügen Sie dem Verzeichnis .github/workflows eine Datei mit dem Namen lint_pr_title.yml und folgendem Inhalt hinzu:

name: "Lint Pull Request Title"

on:
  pull_request_target:
    types:
      - opened
      - edited
      - synchronize

jobs:
  main:
    name: Validate PR title
      runs-on: ubuntu-latest
      steps:
        - uses: amannn/action-semantic-pull-request@v5
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Änderungen per Push an GitHub übertragen

Verwenden Sie schließlich die folgenden Befehle, um die Änderungen an den GitHub-Aktionen zu übernehmen und an GitHub zu übertragen:

git add .github/workflows/
git commit -m "chore: Added github actions"
git push

Zweig main schützen

In der GitHub-UI sollten Sie Branch-Schutzmaßnahmen für den main-Branch aktivieren, damit normale Entwickler Änderungen nicht direkt an diesen Branch übertragen können. Stattdessen nehmen sie Änderungen in einem anderen Zweig vor und öffnen dann eine Pull-Anfrage. Die Pull-Anfrage kann von einem anderen Entwickler geprüft werden, bevor sie genehmigt und mit main zusammengeführt wird.

Rufen Sie zum Konfigurieren des Branch-Schutzes für das Repository die GitHub-UI auf, wählen Sie Settings (Einstellungen) und dann Branches aus und klicken Sie auf die Schaltfläche Add Branch Protection rules (Branch-Schutzregel hinzufügen):

GitHub-UI zum Hinzufügen des Branch-Schutzes

Geben Sie main als Branch-Namensmuster ein und aktivieren Sie die folgenden Optionen:

  • Pull-Anfrage vor dem Zusammenführen verlangen
  • Genehmigungen erforderlich
  • Genehmigungen veralteter Pull-Anfragen werden verworfen, wenn neue Commits übertragen werden

GitHub-UI zum Festlegen von Branch-Schutzoptionen

Klicken Sie abschließend unten auf der Seite auf Erstellen.

Wenn eine Pull-Anfrage erstellt wird, werden die zuvor in dieser Anleitung konfigurierten GitHub-Aktionen ausgeführt. Nachdem sie zum ersten Mal ausgeführt wurden, können sie auch in dieser UI ausgewählt werden, sodass sie erfolgreich sein müssen, bevor die Pull-Anfrage mit main zusammengeführt werden kann.

Pull-Anfragen konfigurieren

In Looker können Sie festlegen, dass Pull-Anfragen verwendet werden, damit Looker im Namen des Entwicklers offene PRs erhält. Dies sollte nur für die Entwicklungsinstanz konfiguriert werden. Die QA- und Produktionsinstanz verwendet den erweiterten Bereitstellungsmodus, um Updates abzurufen.

Rufen Sie dazu für jedes Projekt die Projekteinstellungen auf und wählen Sie unter der Überschrift GitHub-Integration die Option Pull-Anfragen erforderlich aus:

Looker-Benutzeroberfläche zum Anfordern von Pull-Anfragen

Klicken Sie auf die Schaltfläche, um ein Webhook-Secret festzulegen, kopieren Sie den zufällig generierten String und klicken Sie auf die Schaltfläche Save Project Configuration (Projektkonfiguration speichern).

Wählen Sie in der GitHub-Benutzeroberfläche für Ihr Repository Settings (Einstellungen) und dann Webhooks (Webhooks) aus. Klicken Sie rechts oben auf die Schaltfläche Webhook hinzufügen:

  • Geben Sie im Feld Nutzlast-URL https://LOOKER_HOST_NAME/webhooks/projects/PROJECT_NAME/deploy ein.
  • Fügen Sie in das Feld Secret das aus Looker gespeicherte Secret ein.
  • Wählen Sie bei der Frage Welche Ereignisse möchten Sie diesen Webhook auslösen? die Option Ich möchte einzelne Ereignisse auswählen aus.

GitHub-UI zum Konfigurieren von Webhooks

Achten Sie darauf, dass Pull-Anfragen und Pushes ausgewählt sind:

GitHub-Kästchen für Pull- und Push-Anfragen

Klicken Sie abschließend unten auf der Seite auf die Schaltfläche Webhook hinzufügen.

Einrichtungsschritte für jeden Looker-Entwickler

Alle folgenden Installationsschritte sollten in Ihrer Linux-Umgebung ausgeführt werden.

Ruby installieren

Zum Ausführen von Gazer muss die Programmiersprache Ruby installiert sein. Jede Version von Ruby nach Version 2.7.7 funktioniert mit Gazer, aber Ruby 3.x.x wird bevorzugt. Führen Sie die folgenden Befehle aus, um Ruby unter Ubuntu Linux zu installieren:

sudo apt update
sudo apt install ruby

Prüfen Sie, ob Ruby ordnungsgemäß installiert ist, indem Sie ruby -v ausführen. Die Antwort sollte in etwa so aussehen:

ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux]

Diese Befehle funktionieren auch unter Debian Linux, Linux Mint und verschiedenen anderen Linux-Varianten, die den Aptitude-Paketmanager verwenden. Möglicherweise müssen Sie nach Befehlen suchen, die für andere Linux-Varianten funktionieren, oder nach Befehlen, die unter macOS installiert werden sollen. Weitere Informationen finden Sie unter Ruby installieren.

Montage von Gazer

Gazer ist ein Open-Source-Projekt, das von Google-Mitarbeitern erstellt wurde, um über ein Befehlszeilentool in Gruppenbereichen, Looks und Dashboards zu navigieren und diese zu verwalten.

Wenn Ruby installiert ist, kann mit dem Gem-Tool von Ruby Gazer installiert werden:

gem install gazer

Prüfen Sie mit dem Befehl gzr version, ob Gazer installiert ist. Die Antwort sollte in etwa so aussehen:

v0.3.12

Brille installieren

Spectacles ist ein Drittanbietertool zum Testen von LookML. Spectacles bietet sowohl eine kostenpflichtige Version als auch eine Open-Source-Version an. Details zur Installation findest du auf der Seite „Erste Schritte“.

Git installieren

Die Git-Versionsverwaltungssoftware kann unter Ubuntu Linux über den folgenden Befehl installiert werden:

sudo apt update
sudo apt install git

Prüfen Sie mit dem Befehl git --version, ob die Installation erfolgreich war. Die Antwort sollte in etwa so aussehen:

git version 2.42.0.609.gbb76f46606

Diese Befehle funktionieren auch unter Debian Linux, Linux Mint und verschiedenen anderen Linux-Varianten, die den Aptitude-Paketmanager verwenden. Möglicherweise müssen Sie nach Befehlen suchen, die für andere Linux-Varianten funktionieren. Eine Anleitung für Fedora und macOS finden Sie beispielsweise unter Erste Schritte – Git installieren.

Git konfigurieren

Git in Ihrer Linux-Umgebung muss so konfiguriert werden, dass es mit dem Git-Repository interagiert, in dem Ihr LookML gespeichert ist. Diese Anweisungen wurden für LookML-Git-Repositories geschrieben, die in GitHub gespeichert sind.

Name und E-Mail-Adresse

GitHub (und die meisten anderen Git-Implementierungen) müssen Ihren Namen und Ihre E-Mail-Adresse kennen, damit Aktivitäten aufgezeichnet werden können. Konfigurieren Sie Ihren Namen und Ihre E-Mail-Adresse in Git, indem Sie die folgenden Befehle ausführen:

git config --global user.name "FIRST_NAME LAST_NAME"
git config --global user.email "EMAIL_ADDRESS"

Git-Anmeldedaten

Bei der ersten CI/CD-Einrichtung wurden git-Anmeldedaten erstellt. Der generierte private SSH-Schlüssel sollte in einer $HOME/.ssh/config-Datei konfiguriert werden. Verwenden Sie die folgenden Befehle, um die Datei zu erstellen:

touch $HOME/.ssh/config
chmod 600 $HOME/.ssh/config

Fügen Sie den folgenden Text in die Datei $HOME/.ssh/config ein:

Host github.com
  User git
  IdentityFile ~/.ssh/KEY_NAME
  ControlMaster auto
  ControlPath ~/.ssh/ctrl-%r@%h:%p
  ControlPersist yes

Verwenden Sie anstelle von KEY_NAME den Namen der privaten Schlüsseldatei, die Sie in der Anleitung Neuen SSH-Schlüssel zu Ihrem GitHub-Konto hinzufügen generiert haben. Die Datei mit dem privaten Schlüssel hat denselben Namen wie die öffentliche Schlüsseldatei, hat aber die Erweiterung .pub. Wenn du beispielsweise den öffentlichen Schlüssel aus der Datei id_ed25519.pub verwendet hast, lautet der Name des privaten Schlüssels id_ed25519.

Lokales Git-Repository einrichten

Nachdem Sie Ihr LookML-Repository konfiguriert haben, müssen Sie eine Kopie davon in Ihrer Linux-Umgebung erstellen. Führen Sie dazu den folgenden Befehl aus:

git clone GIT_URL

Der Befehl könnte beispielsweise so aussehen:

git clone git@github.com:my_org_name/sales_project.git

Dadurch wird das LookML-Repository in ein Unterverzeichnis kopiert, z. B. sales_project. Rufen Sie das Repository mit dem Befehl cd SUB_DIRECTORY auf. In diesem Beispiel lautet der Befehl cd sales_project.

Im Verzeichnis Ihres Repositorys können Sie dann die folgenden Befehle verwenden:

Befehl Zweck
git checkout BRANCH_NAME Wird zum Wechseln von Zweigen verwendet. In den meisten Fällen heißt der primäre Zweig main. In älteren Systemen kann er jedoch master heißen.
git fetch Wird zum Abrufen der neuesten Änderungen vom Server verwendet.
git pull Wird verwendet, um Änderungen an den ausgecheckten lokalen Dateien anzuwenden. git pull führt implizit eine git fetch aus.
git tag Wird zum Erstellen eines aussagekräftigen Tags für eine bestimmte Überarbeitung verwendet.
git push Werden verwendet, um lokale Änderungen auf den Server zu übertragen.

Gazer konfigurieren

Zur Verwendung von Gazer benötigen Sie API-Anmeldedaten für jede der Entwicklungs-, QA- und Produktionsinstanzen. Eine Anleitung zum Erstellen von API-Anmeldedaten finden Sie auf der Seite Administratoreinstellungen – Nutzer. Die API-Anmeldedaten wurden möglicherweise bereits von der Person erstellt, die den CI/CD-Workflow eingerichtet hat. In diesem Fall können Sie die vorhandenen Anmeldedaten verwenden. Es müssen nicht für jede Person neue Anmeldedaten generiert werden.

Speichern Sie Ihre API-Anmeldedaten in einer .netrc-Datei mit minimalen Berechtigungen in Ihrem Basisverzeichnis. Mit den folgenden Befehlen können Sie eine leere Datei mit den entsprechenden Berechtigungen erstellen:

touch $HOME/.netrc
chmod 600 $HOME/.netrc

Fügen Sie der Datei Einträge wie den folgenden hinzu. Verwenden Sie dabei jedoch Ihre eigenen Looker-Serverhostnamen für machine, die API client_id für die Anmeldung und die API client_secret für das Passwort. Beispiel:

machine dev.example.looker.com
  login 80ka7nl6lj87ftmn
  password u7kw3mj5h2trfz0

machine qa.example.looker.com
  login fi3qtv5at5crvd1q
  password bdxtaeghnzyz0wm

machine example.looker.com
  login k7lr6yv57wvzy9p2
  password wcvr5qjd2isbs2s

Testen Sie, ob dies funktioniert, indem Sie einen einfachen Gazer-Befehl für jeden Server ausführen, z. B.:

gzr user me --host dev.example.looker.com

Das Ergebnis sollte in etwa so aussehen:

+----+---------------+---------+----------+------------------+--------------+
|  id|email          |last_name|first_name|personal_folder_id|home_folder_id|
+----+---------------+---------+----------+------------------+--------------+
|2345|jsm@example.com|Smith    |John      |              2161|           708|
+----+---------------+---------+----------+------------------+--------------+

Wenn der vorherige Befehl nicht funktioniert, müssen Sie möglicherweise --port 443 am Ende des Befehls gzr hinzufügen. Gehen Sie dazu so vor:

gzr user me --host dev.example.looker.com --port 443

Brille konfigurieren

Spectacles verwendet dieselbe API client_id und client_secret wie Gazer. Erstellen Sie im Spectacles-Verzeichnis für jede Stufe eine Datei mit dem Namen config-TIER.yaml, z. B. config-dev.yaml. Fügen Sie den Dateien je nach Looker-Instanz dieser Stufe den folgenden Inhalt hinzu, z. B.:

config-dev.yaml

base_url: https://dev.example.looker.com/
client_id: 80ka7nl6lj87ftmn
client_secret: u7kw3mj5h2trfz0

config-qa.yaml

base_url: https://qa.example.looker.com/
client_id: fi3qtv5at5crvd1q
client_secret: bdxtaeghnzyz0wm

config-prod.yaml

base_url: https://example.looker.com/
client_id: k7lr6yv57wvzy9p2
client_secret: wcvr5qjd2isbs2s

Sie können jede Datei testen, indem Sie den folgenden Befehl ausführen und jeden Dateinamen ersetzen:

$ spectacles connect --config-file config-dev.yaml

Sie sollten eine Antwort ähnlich der folgenden erwarten:

Connected to Looker version 23.18.60 using Looker API 4.0