Zu Workspace

Version 3.1.23.2

Arbeitsbereich anfordern

Gibt Informationen zu einem Arbeitsbereich zurück, z. B. den Git-Status und ausgewählte Zweige aller Projekte, die dem Nutzerkonto des Anrufers zur Verfügung stehen.

Ein Arbeitsbereich definiert, welche Versionen von Projektdateien zum Bewerten von Ausdrücken und Vorgängen verwendet werden, die Modelldefinitionen verwenden, z. B. Vorgänge wie das Ausführen von Abfragen oder das Rendering von Dashboards. Jedes Projekt hat ein eigenes Git-Repository und jedes Projekt in einem Arbeitsbereich kann so konfiguriert sein, dass es auf einen bestimmten Zweig oder eine Überarbeitung in den entsprechenden Repositories verweist.

Es gibt zwei vordefinierte Arbeitsbereiche: „Produktion“ und „Entwicklung“.

Der Produktionsarbeitsbereich wird für alle Looker-Nutzer freigegeben. Modelle im Produktionsarbeitsbereich sind schreibgeschützt. Zum Ändern von Dateien in der Produktion müssen Sie Dateien in einem Git-Zweig ändern und Pull-Anfragen verwenden, um die Änderungen aus dem Entwicklungszweig mit dem Produktionszweig zusammenzuführen und dann Looker anzuweisen, mit der Produktion zu synchronisieren.

Der Entwicklungsarbeitsbereich ist für jeden Looker-Nutzer lokal. Änderungen an Projekt-/Modelldateien im Entwicklerarbeitsbereich wirken sich nur auf diesen Nutzer aus und nur dann, wenn der Entwicklerarbeitsbereich als aktiver Arbeitsbereich für die API-Sitzung ausgewählt wird. Weitere Informationen finden Sie unter „set_session_workspace()“.

Der Entwicklungsarbeitsbereich ist NICHT speziell für eine API-Sitzung. Zwei Anwendungen, die über dasselbe Nutzerkonto auf die Looker API zugreifen, sehen im Entwicklungsarbeitsbereich dieselben Dateien. Um Konflikte zwischen API-Clients zu vermeiden, empfiehlt es sich, für jeden Client Anmeldedaten mit API3 für ein anderes Nutzerkonto zu verwenden.

Änderungen an Dateien in einem Entwicklerarbeitsbereich werden für alle API-Sitzungen übernommen. Es ist eine gute Idee, alle Änderungen, die Sie am Git-Repository vorgenommen haben, zu übernehmen, aber nicht zwingend erforderlich. Die geänderten Dateien befinden sich in einem speziellen nutzerspezifischen Verzeichnis auf dem Looker-Server. Sie bleiben vorhanden, wenn Sie sich später wieder anmelden und mit dem Befehl „update_session(workspace_id: „dev“)“ den Entwicklerarbeitsbereich für die neue API-Sitzung auswählen.

Anfrage

GET /workspaces/{workspace_id}
Datentyp
Beschreibung
Anfrage
HTTPRequest
Pfad
HTTPPath
HTTPPath-Definition maximieren...
Arbeitsbereich_ID
String
ID des Arbeitsbereichs

Antwort

200: Google Workspace

Datentyp
Beschreibung
(Objekt)
kann
Objekt
Vorgänge, die der aktuelle Nutzer für dieses Objekt ausführen kann
id
String
Die eindeutige ID dieses Arbeitsbereichs. Vordefinierte Arbeitsbereichs-IDs enthalten „Produktion“ und „Entwicklung“
projects
Projektdefinition maximieren...
kann
Objekt
Vorgänge, die der aktuelle Nutzer für dieses Objekt ausführen kann
id
String
Projekt-ID
name
String
Anzeigename des Projekts
verwendet_git
boolean
Bei „true“ wurde das Projekt mit einem Git-Repository konfiguriert
Git_Remote_URL
String
URL des Git-Remote-Repositorys
Git-Nutzername
String
Git-Nutzername für die HTTPS-Authentifizierung. (Nur für die Produktion, wenn Nutzerattribute verwendet werden.)
Git-Passwort
String
(Nur-Schreibzugriff) Git-Passwort für die HTTPS-Authentifizierung. (Nur für die Produktion, wenn Nutzerattribute verwendet werden.)
Git_Production-Zweigname
String
Name der Git-Produktionszweig: Die Standardeinstellung ist „Master“. Wird nur in Looker 21.0 und höher unterstützt.
Verwendung von „git_cookie_auth“
boolean
Bei „true“ verwendet das Projekt ein Git-Cookie für die Authentifizierung.
„git_username_user_attribute“
String
Nutzerattributname für den Nutzernamen in der HTTPS-Authentifizierung pro Nutzer.
„git_password_user_attribute“
String
Nutzerattributname für das Passwort in der HTTPS-Authentifizierung pro Nutzer.
Git_Service_Name
String
Name des Git-Dienstanbieters
Git_Application_Server_http_Port
integer
Port, auf dem der HTTP(S)-Server ausgeführt wird (für PRs, Dateisuche usw.)
Git_Application_Server_http_Schema
String
Schema, das auf dem Nameserver ausgeführt wird (für PRs, Dateisuche usw.)
Secret bereitstellen
String
(Nur Schreibzugriff) Optionales geheimes Token, mit dem Anfragen an den Webhook-Bereitstellungsendpunkt authentifiziert werden. Wenn dies nicht festgelegt ist, ist der Endpunkt nicht authentifiziert.
Nicht festgelegt_deploy_secret
boolean
(Nur Schreibzugriff) Wenn für „true“ festgelegt, wird die Bereitstellung des Secrets beendet, um nicht authentifizierten Zugriff auf den Webhook-Endpunkt der Bereitstellung zu ermöglichen.
Pull-Modus "Anfrage"
String
Die Richtlinie für die Git-Pull-Anfrage für dieses Projekt. Gültige Werte sind: „off“, „links“, „recommended“ und „required“.
Validierung_erforderlich
boolean
Validierungsrichtlinie: Wenn dieser Wert auf „true“ gesetzt ist, muss das Projekt die Validierungsprüfungen bestehen, bevor Projektänderungen an das Git-Repository übergeben werden können
Git_release_mgmt_enabled
boolean
Bei "true" ist die erweiterte Git-Releaseverwaltung für dieses Projekt aktiviert
allow_warnings
boolean
Validierungsrichtlinie: Wenn "true", kann für das Projekt ein Commit mit Warnungen durchgeführt werden, wenn "validierung_required" wahr ist. „allow_warnings“ löst nichts aus, wenn „validierung_required“ auf „false“ festgelegt ist.
Ist_Beispiel
boolean
Bei „true“ ist das Projekt ein Beispielprojekt und kann nicht geändert werden

400: Ungültige Anfrage

Datentyp
Beschreibung
(Objekt)
nachricht
String
Fehlerdetails
Dokumentations-URL
String
Link zur Dokumentation

404: Nicht gefunden

Datentyp
Beschreibung
(Objekt)
nachricht
String
Fehlerdetails
Dokumentations-URL
String
Link zur Dokumentation

Beispiele