Obtener Workspace

Versión 4.0.23.2

Obtener un lugar de trabajo

Muestra información sobre un lugar de trabajo, como el estado de Git y las ramas seleccionadas de todos los proyectos disponibles para la cuenta de usuario del emisor.

Un lugar de trabajo define qué versiones de los archivos del proyecto se usarán para evaluar expresiones y operaciones que usan definiciones de modelos, como operaciones de ejecución de consultas o paneles de renderización. Cada proyecto tiene su propio repositorio de Git, y cada proyecto de un lugar de trabajo puede configurarse para hacer referencia a una rama o revisión en particular dentro de sus respectivos repositorios.

Hay dos lugares de trabajo predefinidos disponibles: “producción” y “Desarrollo”.

El lugar de trabajo de producción se comparte entre todos los usuarios de Looker. Los modelos del lugar de trabajo de producción son de solo lectura. El cambio de archivos en producción se logra modificando los archivos en una rama de Git y usando solicitudes de extracción para combinar los cambios de la rama dev con la rama de producción, y luego indicarle a Looker que se sincronice con producción.

El lugar de trabajo de desarrollo es local para cada usuario de Looker. Los cambios realizados en los archivos del proyecto o modelo en el lugar de trabajo de desarrollo solo afectan a ese usuario y solo cuando este se selecciona como el lugar de trabajo activo para la sesión de la API. (Consulta set_session_workspace()).

El lugar de trabajo de desarrollo NO es exclusivo de una sesión de API. Dos aplicaciones que acceden a la API de Looker con la misma cuenta de usuario verán los mismos archivos en el lugar de trabajo de desarrollo. A fin de evitar colisiones entre los clientes de la API, es mejor tener cada acceso de cliente con credenciales de API3 para una cuenta de usuario diferente.

Los cambios realizados en los archivos de un lugar de trabajo de desarrollo son persistentes en todas las sesiones de la API. Te recomendamos que confirmes los cambios que hiciste en el repositorio de Git, pero que no son estrictamente obligatorios. Tus archivos modificados residen en un directorio especial específico del usuario en el servidor de Looker y aún estarán allí cuando vuelvas a acceder más tarde y uses update_session(workspace_id: "dev") a fin de seleccionar el lugar de trabajo de desarrollo para la nueva sesión de la API.

Solicitud

OBTENER /workspaces/{workspace_id}
Tipo de datos
Descripción
Solicitud
HTTPRequest
ruta
Ruta de HTTP
Expandir la definición HTTPPath...
id_lugar de trabajo
string
ID del lugar de trabajo

Respuesta

200: Workspace

Tipo de datos
Descripción
(objeto)
que pueden
objeto
Operaciones que el usuario actual puede realizar en este objeto
id
string
Es el ID único de este lugar de trabajo del usuario. Los ID predefinidos del lugar de trabajo incluyen "producción" y "desarrollo"
projects
Expandir la definición del proyecto...
que pueden
objeto
Operaciones que el usuario actual puede realizar en este objeto
id
string
ID del proyecto
del espacio
string
Nombre visible del proyecto
uses_git
booleano
Si es verdadero, el proyecto se configura con un repositorio de Git.
git_remote_url
string
URL del repositorio remoto de Git
Git_nombre de usuario
string
Nombre de usuario de Git para la autenticación HTTPS. (Solo para producción, si se usan atributos de usuario).
Git_contraseña
string
(Solo escritura) Contraseña de Git para la autenticación HTTPS. (Solo para producción, si se usan atributos de usuario).
git_production_branch_name
string
Nombre de la rama de producción de Git. La configuración predeterminada es la instancia principal. Solo compatible con Looker 21.0 y versiones posteriores.
use_git_cookie_auth
booleano
Si es verdadero, el proyecto usa una cookie de Git para la autenticación.
git_nombre_usuario_atributo
string
Nombre del atributo del usuario para el nombre de usuario en la autenticación HTTPS por usuario.
git_password_user_attribute
string
Nombre del atributo del usuario para la contraseña en la autenticación HTTPS por usuario.
Nombre del servicio de Git
string
Nombre del proveedor de servicios de Git
puerto git_application_server_http_port
integer
Puerto en el que se ejecuta el servidor de aplicaciones HTTP(S) (para relaciones públicas, navegación de archivos, etcétera)
Git_application_server_http_scheme
string
Scheme que se ejecuta en el servidor de aplicaciones (para RR.PP., navegación de archivos, etcétera)
implementación_secreta
string
(Solo escritura) Token secreto opcional con el que se autentican las solicitudes al extremo de implementación de webhook. Si no se configura, el extremo no está autenticado.
Secret_deploy_secret
booleano
(Solo escritura) Cuando es verdadero, configura el secreto de implementación para permitir el acceso no autenticado al extremo de implementación del webhook.
Modo de solicitud de extracción
string
La política de solicitud de extracción de Git para este proyecto. Los valores válidos son “off”, “links”, “recommended”, “required”.
validación_requerida
booleano
Política de validación: Si es verdadero, el proyecto debe pasar las verificaciones de validación antes de que los cambios del proyecto puedan confirmarse en el repositorio de Git.
git_release_mgmt_enabled
booleano
Si es verdadero, la administración de versiones de Git avanzada está habilitada para este proyecto
allow_warnings
booleano
Política de validación: Si es verdadero, el proyecto se puede confirmar con advertencias cuando el campo "validation_required" es verdadero. (`allow_warnings` no hace nada si `validation_required` es falsa).
es_ejemplo
booleano
Si es verdadero, el proyecto es un ejemplo y no se puede modificar.
estado_de_dependencia
string
Estado de las dependencias en tu manifiesto y archivo de bloqueo

400: Bad Request

Tipo de datos
Descripción
(objeto)
mensaje,
string
Detalles del error
url_documentación
string
Vínculo a la documentación

404: No encontrado

Tipo de datos
Descripción
(objeto)
mensaje,
string
Detalles del error
url_documentación
string
Vínculo a la documentación

Ejemplos