Build Workflow

El único orden de workflow que escala

Looky es determinístico cuando construyes en este orden. Si inviertes los pasos, te quedan fallas ambiguas y delivery lenta.

1. La estructura y el contexto del workspace están correctos.
2. Los aliases de runtime sources están definidos y son válidos.
3. Los models Malloy exponen contratos de query estables e idiomáticos (capa semántica, named views — no SQL ad-hoc esparcido por todo el viz YAML).
4. Las visualizations mapean campos de query a renderers.
5. Los dashboards componen visualizations validadas.
6. Validate, diff, push, y verificar en la UI.

La cadena canónica dentro de un workspace

Cada workspace de Looky son las mismas cuatro capas, en este orden de dependencia — lee los archivos de tu workspace en este orden cada vez que necesites debuggear o extender:

• runtime/sources.runtime.yml declara aliases de source (ej.: un alias ecommerce apuntando a un dataset de BigQuery, o a un connection string de Postgres / MySQL).
• content/models/*.malloy define dimensions, measures y queries con nombre reutilizables sobre esos aliases de source.
• content/visualizations/*.yml conecta una query de model con un renderer de chart/table.
• content/dashboards/*.yml compone visualizations en las superficies finales que ve la audiencia.

Cada capa referencia solo la de arriba. Si una capa falla la validación, arreglala antes de tocar nada debajo — las capas debajo no pueden recuperarse solas.

Un workspace, de punta a punta

Los cuatro archivos de abajo son un workspace completo y funcional contra el dataset público de ecommerce de BigQuery — lo más pequeño que vale la pena publicar. Cada página siguiente elabora una de estas capas.

runtime/sources.runtime.yml:

sources:
  ecommerce:
    name: The Look Ecommerce
    type: bigquery
    project_id: my-gcp-billing-project
    credentials_file: my-workspace-bq.json
    datasets:
      - bigquery-public-data.thelook_ecommerce

content/models/ec_revenue.malloy:

##! experimental.parameters

source: ec_revenue() is ecommerce.table('bigquery-public-data.thelook_ecommerce.order_items') extend {
  dimension: order_month is created_at::date.month
  measure: revenue is sum(sale_price)
  measure: order_count is count(order_id)

  view: kpi is {
    aggregate: revenue, order_count
  }

  view: over_time is {
    group_by: order_month
    aggregate: revenue
    order_by: order_month asc
  }
}

content/visualizations/ec_revenue_kpi.yml y content/visualizations/ec_revenue_over_time_line.yml:

id: ec_revenue_kpi
title: Revenue
query: "models/ec_revenue.malloy::kpi"
type: kpi
mapping:
  value: revenue
format:
  revenue: "$#,##0a"
published: true

id: ec_revenue_over_time_line
title: Revenue over time
query: "models/ec_revenue.malloy::over_time"
type: line
mapping:
  x: order_month
  y: revenue
format:
  revenue: "$#,##0"
published: true

content/dashboards/ec_revenue_overview.yml:

id: ec_revenue_overview
title: "Where is revenue going?"
layout_mode: fluid_grid
published: true
items:
  - visualization: ec_revenue_kpi
  - visualization: ec_revenue_over_time_line
    width: 2

Con esos archivos en su lugar, looky validate y luego looky push ponen el dashboard frente a los usuarios del workspace.

Loop de builder que tienes que correr todos los días

cd <local_root>/<billing_account_id>/<workspace_slug>
looky status
looky validate
looky diff
looky push
looky list visualizations
looky list dashboards

Corre este loop por cada cambio significativo. Atrapa issues estructurales antes de que los usuarios vean dashboards rotos.

Definition of done para un cambio de contenido

• looky validate no tiene errores bloqueantes.
• looky diff solo muestra archivos intencionados.
• looky push tiene éxito en el workspace target.
• El dashboard es visible y renderiza correcto en https://my.looky.studio.