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.

In dieser Anleitung wird ein dreistufiges System verwendet, das Entwicklung, QA und Produktion umfasst. Dieselben Prinzipien können jedoch auch auf ein zweistufiges oder vierstufiges System angewendet werden.

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

Folgen Sie der Anleitung im entsprechenden Abschnitt:

Vorbereitung

Linux-Umgebung

Dabei werden die Tools Gazer und Spectacles verwendet, die für die Verwendung mit Unix-ähnlichen Betriebssystemen konzipiert sind. 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 für 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 der umfassenden Unterstützung eine gute Wahl.

Diese Anleitung enthält Beispiele für Linux-Systeme und muss möglicherweise angepasst werden, wenn Sie macOS oder WSL verwenden.

Eine Looker-Instanz pro Stufe

Für diese Konfiguration benötigen Sie eine Looker-Instanz für jede Ebene Ihres Systems. Für ein System mit einer Entwicklungsphase, einer QA-Phase und einer Produktionsphase sind beispielsweise drei separate Instanzen erforderlich. Die Instanzen können von Google oder vom Kunden gehostet werden.

Identische Verbindungsnamen

Datenbankverbindungen sollten in jeder Looker-Instanz denselben Namen haben, unabhängig davon, welche Ebene sie repräsentieren. Eine sales-Verbindung sollte beispielsweise in allen Instanzen diesen Namen haben, nicht sales_dev oder sales_qa.

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

Wenn beispielsweise dieselbe Datenbank für alle drei Instanzen verwendet wird, können sie 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 dieselbe Datenbank verwendet wird, können sie so 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 in allen drei Ebenen ein einzelnes Git-Repository verwendet. Die Entwicklungsinstanz verfolgt den main-Branch, während die QA- und Produktionsinstanzen in der Regel auf Git-Tags verweisen (wird später ausführlicher beschrieben).

Einrichtungsschritte nur bei der Ersteinrichtung

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

Git-Anmeldedaten

Die Linux-Umgebung jedes Entwicklers muss mit demselben Repository verbunden sein, das Sie zum Verwalten Ihrer LookML 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 Neuem SSH-Schlüssel zu Ihrem 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 verknüpft sein. In den Projekteinstellungen muss Git-Produktionszweigname auf main festgelegt und Erweiterten Bereitstellungsmodus aktivieren 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 (wahrscheinlich Ihre Organisation) aus und geben Sie eine REPOSITORY_NAME ein.
  3. Wählen Sie aus, ob das Repository öffentlich oder privat sein soll (für private Repositories ist ein kostenpflichtiges GitHub-Abo erforderlich). Klicken Sie dann auf das Kästchen, 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 ungefähr so aus: git@github.com:org_name/REPOSITORY_NAME.git.
  6. Erstellen Sie in Looker ein neues Projekt.
  7. Wechseln Sie in den Entwicklungsmodus, wählen Sie in der linken Seitenleiste die Projekteinstellungen und dann Git konfigurieren aus.
  8. Fügen Sie die Repository-URL ein (git@github.com:org_name/REPOSITORY_NAME.git in diesem Beispiel) und wählen Sie Continue (Weiter) aus.
  9. Kopieren Sie den Bereitstellungsschlüssel und kehren Sie zur GitHub-Benutzeroberfläche für dieses Repository zurück.
  10. Wählen Sie Einstellungen und dann Deploy-Schlüssel 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 Looker-REPOSITORY_NAME hinzu, klicken Sie das Kästchen Schreibzugriff zulassen an und drücken Sie die Schaltfläche Schlüssel hinzufügen.
  13. Kehren Sie zu Looker zurück und wählen Sie Einrichtung testen und abschließen aus.
  14. Wählen Sie in der linken Seitenleiste noch einmal die Projekteinstellungen aus. Ändern Sie den Namen des Git-Produktionszweigs in main.
  15. Wählen Sie Erweiterten Bereitstellungsmodus aktivieren und Projektkonfiguration speichern aus.

Unter dem Symbol für die Projekteinstellungen auf der linken Seite sollte ein Bereitstellungssymbol für den Deployment Manager angezeigt werden.

Vorhandenes Repository verwenden

  1. Rufen Sie das GitHub-Repository auf, in dem Ihre LookML gespeichert ist.
  2. Klicken Sie auf die grüne Schaltfläche <> Code und kopieren Sie die SSH-URL. Sie sieht ungefähr so aus: git@github.com:org_name/REPOSITORY_NAME.git.
  3. Erstellen Sie in Looker ein neues Projekt.
  4. Wechseln Sie in den Entwicklungsmodus und wählen Sie in der linken Seitenleiste die Projekteinstellungen und dann Git konfigurieren aus.
  5. Fügen Sie die Repository-URL ein (git@github.com:org_name/REPOSITORY_NAME.git in diesem Beispiel) und wählen Sie Continue (Weiter) aus.
  6. Kopieren Sie den Bereitstellungsschlüssel und kehren Sie zur GitHub-Benutzeroberfläche für dieses Repository zurück.
  7. Wählen Sie Einstellungen und dann Deploy-Schlüssel 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 Looker-REPOSITORY_NAME hinzu, klicken Sie das Kästchen Schreibzugriff zulassen an und drücken Sie die Schaltfläche Schlüssel hinzufügen.
  10. Kehren Sie zu Looker zurück und wählen Sie Einrichtung testen und abschließen aus.
  11. Wählen Sie in der linken Seitenleiste noch einmal die Projekteinstellungen aus. Ändern Sie den Namen des Git-Produktionszweigs in main.
  12. Wählen Sie Erweiterten Bereitstellungsmodus aktivieren und Projektkonfiguration speichern aus.

Unter dem Symbol für die Projekteinstellungen auf der linken Seite sollte ein Bereitstellungssymbol für den Deployment Manager angezeigt werden.

GitHub-Aktionen erstellen

Es ist sinnvoll, mehrere GitHub-Aktionen zu erstellen, damit bei jeder Änderung an der LookML 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. Falls das nicht der Fall ist, folgen Sie der Anleitung unter Git konfigurieren.

Wenn Sie die GitHub-Aktionen hinzufügen möchten, rufen Sie das Verzeichnis Ihres Repositories 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 Actions (Aktionen) in der GitHub-Benutzeroberfläche ausgeführt werden.

Look-At-Me-Sideways (LAMS)

LAMS ist ein Open-Source-Linter, der Ihre LookML auf Fehler und schlechte Praktiken prüft. Fügen Sie dem Verzeichnis .github/workflows eine Datei mit dem Namen lams.yml mit 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 auf GitHub gepusht oder eine Pull-Anfrage geöffnet wird, um Code mit dem main-Zweig zusammenzuführen, wird LAMS ausgeführt.

Bitte veröffentlichen

Release Please ist ein Open-Source-Tool, mit dem Releases automatisch mit den richtigen Versionsnummern getaggt werden.

Fügen Sie dem Verzeichnis .github/workflows eine Datei mit dem Namen release-please.yml mit 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

Konventionelle Commits

Mit dieser GitHub-Aktion wird sichergestellt, dass eine Pull-Anfrage mit einem Titel geöffnet wird, der dem konventionellen Commit-Standard entspricht.

Fügen Sie dem Verzeichnis .github/workflows eine Datei mit dem Namen lint_pr_title.yml mit 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 auf GitHub übertragen

Übernehmen Sie die Änderungen an den GitHub-Aktionen mit den folgenden Befehlen und übertragen Sie sie auf GitHub:

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

main-Branch schützen

Aktivieren Sie in der GitHub-Benutzeroberfläche den Schutz von Branches für den Branch main, damit normale Entwickler keine Änderungen direkt in diesen Branch pushen können. Stattdessen nimmt er Änderungen in einem anderen Branch vor und öffnet dann einen Pull-Request. Der Pull-Request kann von einem anderen Entwickler geprüft werden, bevor er genehmigt und mit main zusammengeführt wird.

Wenn Sie die Branch Protection konfigurieren möchten, rufen Sie die GitHub-Benutzeroberfläche für das Repository auf, wählen Sie Einstellungen und dann Branches aus und klicken Sie auf die Schaltfläche Branch Protection Rule hinzufügen:

GitHub-Benutzeroberfläche zum Hinzufügen von Zweigschutz

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

  • Pull-Request vor dem Zusammenführen erzwingen
  • Genehmigungen erforderlich machen
  • Abgelaufene Pull-Request-Genehmigungen zurückweisen, wenn neue Commits gepusht werden

GitHub-Benutzeroberfläche zum Festlegen von Optionen für den Branch-Schutz

Klicken Sie abschließend unten auf der Seite auf die Schaltfläche Erstellen.

Wenn eine Pull-Anfrage erstellt wird, werden die GitHub-Aktionen ausgeführt, die in dieser Anleitung zuvor konfiguriert wurden. Nach der ersten Ausführung können sie auch in dieser Benutzeroberfläche ausgewählt werden, sodass sie erfolgreich abgeschlossen werden müssen, bevor der Pull-Request in main zusammengeführt werden kann.

Pull-Anfragen konfigurieren

In Looker können Sie die Verwendung von Pull-Anfragen vorschreiben und Looker dazu veranlassen, Pull-Anfragen im Namen des Entwicklers zu öffnen. Diese Einstellung sollte nur für die Entwicklungsinstanz konfiguriert werden. Die QA- und Produktionsinstanz verwenden den erweiterten Bereitstellungsmodus, um ihre Updates zu erhalten.

Aktivieren Sie diese Option, indem Sie für jedes Projekt die Seite Projektkonfiguration aufrufen und dann unter der Überschrift GitHub-Integration die Option Pull-Anfragen erforderlich auswählen.

Klicken Sie auf die Schaltfläche, um ein Webhook-Secret festzulegen, kopieren Sie den generierten Zufallsstring und klicken Sie auf die Schaltfläche Projektkonfiguration speichern.

Wählen Sie in der GitHub-Benutzeroberfläche für Ihr Repository Einstellungen und dann 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 im Feld Secret das Secret ein, das Sie in Looker gespeichert haben.
  • Wählen Sie bei der Frage Welche Ereignisse sollen diesen Webhook auslösen? die Option Einzelne Ereignisse auswählen aus.

GitHub-Benutzeroberfläche zum Konfigurieren von Webhooks

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

Kästchen für Pull-Anfragen und Pushes in GitHub

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

Die Programmiersprache Ruby muss installiert sein, damit Gazer ausgeführt werden kann. Jede Ruby-Version ab 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 richtig installiert ist. Führen Sie dazu ruby -v aus. Sie sollten eine Antwort ähnlich der folgenden erhalten:

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

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

Gazer installieren

Gazer ist ein Open-Source-Projekt, das von Google-Mitarbeitern entwickelt wurde, um Gruppenbereiche, Looks und Dashboards über ein Befehlszeilentool zu verwalten.

Wenn Ruby installiert ist, können Sie Gazer mit dem Ruby-Gem-Tool installieren:

gem install gazer

Prüfen Sie mit dem Befehl gzr version, ob Gazer installiert ist. Sie sollten eine Antwort ähnlich der folgenden erhalten:

v0.3.12

Spectacles installieren

Spectacles ist ein Drittanbietertool zum Testen von LookML. Spectacles bietet sowohl eine kostenpflichtige Version als auch eine Open-Source-Version. Details zur Installation finden Sie auf der Startseite.

Git installieren

Die Git-Versionskontrollsoftware kann unter Ubuntu Linux mit dem folgenden Befehl installiert werden:

sudo apt update
sudo apt install git

Prüfen Sie mit dem Befehl git --version, ob die Installation erfolgreich war. Sie sollten eine Antwort ähnlich der folgenden erhalten:

git version 2.42.0.609.gbb76f46606

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

Git konfigurieren

Git in Ihrer Linux-Umgebung muss so konfiguriert sein, dass es mit dem Git-Repository interagieren kann, in dem Ihre LookML gespeichert ist. Diese Anleitung gilt für LookML-Git-Repositories, die in GitHub gespeichert sind.

Name und E-Mail-Adresse

GitHub (und die meisten anderen Git-Implementierungen) benötigen Ihren Namen und Ihre E-Mail-Adresse, damit Aktivitäten aufgezeichnet werden können. Konfigurieren Sie Ihren Namen und Ihre E-Mail-Adresse in Git. Führen Sie dazu die folgenden Befehle aus:

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 mithilfe der Anleitung zum Hinzufügen eines neuen SSH-Schlüssels zu Ihrem GitHub-Konto generiert haben. Die private Schlüsseldatei hat denselben Namen wie die öffentliche Schlüsseldatei, aber ohne die Dateiendung .pub. Wenn Sie beispielsweise den öffentlichen Schlüssel in der Datei id_ed25519.pub verwenden, hat der private Schlüssel den Namen 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 diesen 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. Verwenden Sie den Befehl cd SUB_DIRECTORY, um das Repository aufzurufen. In diesem Beispiel wäre das cd sales_project.

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

Befehl Zweck
git checkout BRANCH_NAME Wird zum Wechseln zwischen Zweigen verwendet. In den meisten Fällen heißt der Hauptzweig main. In älteren Systemen kann er aber auch master heißen.
git fetch Wird verwendet, um die neuesten Änderungen vom Server abzurufen.
git pull Wird verwendet, um Änderungen auf die lokalen Dateien anzuwenden, die Sie ausgecheckt haben. git pull führt implizit eine git fetch aus.
git tag Wird verwendet, um ein aussagekräftiges Tag für eine bestimmte Version zu erstellen.
git push Wird verwendet, um lokale Änderungen auf den Server zu übertragen.

Gazer konfigurieren

Für die Verwendung von Gazer benötigen Sie API-Anmeldedaten für jede Entwicklungs-, QA- und Produktionsinstanz. Eine Anleitung zum Erstellen von API-Anmeldedaten finden Sie auf der Seite Verwaltung – Nutzer. Die API-Anmeldedaten wurden möglicherweise bereits von der Person erstellt, die den CI/CD-Workflow ursprünglich 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 richtigen Berechtigungen erstellen:

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

Fügen Sie der Datei Einträge wie die folgenden hinzu, verwenden Sie jedoch Ihre eigenen Looker-Server-Hostnamen 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 auf jedem Server ausführen, z. B. den folgenden:

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

Spectacles konfigurieren

Spectacles verwendet dieselben APIs client_id und client_secret wie Gazer. Erstellen Sie in Ihrem Spectacles-Verzeichnis für jede Stufe eine Datei mit dem Namen config-TIER.yaml, z. B. config-dev.yaml. Fügen Sie den Dateien den folgenden Inhalt hinzu, der für die Looker-Instanz dieser Stufe geeignet ist:

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 dabei den jeweiligen Dateinamen ersetzen:

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

Sie sollten eine Antwort ähnlich der folgenden erhalten:

Connected to Looker version 23.18.60 using Looker API 4.0