📄Creating a new project

A Euno project serves as an exclusive repository for aggregating data products linked to a specific account or data domain. Essentially, a project embodies a dynamic and continuously evolving compilation of text files, collectively sculpting and elucidating the extensive data model it signifies. Notably, a Euno project maintains a one-to-one correspondence with a dbt project. This segment will walk you through the nuances of overseeing and advancing projects, providing valuable insights into the smooth integration of data across various accounts and domains.

Account Home Screen

Connecting to a Github Repository

When initiating a new project through the "Create a new dbt project" button on the homepage, a dialog box will appear, prompting you to provide the following details:

• Project name

• Repository

• Branch

To include a directory path for the dbt project, you can access this option by clicking on the "Advanced" setting.

Create New Project

Upon successful configuration, the user will be directed to the project's home page. If any issues arise, an error message will be shown in the dialogue box in red text.

Selecting a Job

For Euno to support automated code generation, data model visualization, and the data app sync, it requires specific artifacts from the dbt build: catalog.json, manifest.json, and run_results.json. Additionally, the following information is required from a job responsible for building the "entire" data model, or the portion considered as such by your organization. Since not every job serves the same function, it is essential to choose the job you want Euno to process.

The selected job must meet the following three criteria:

1. It must be a build, not just a compile.

2. The option "Generate docs on run" must be selected.

3. The job should be set to build the "entire" data model or the specific part of the data model your organization wants to view in Euno.

If you do not have an existing job that meets the above criteria and you are concerned about the build cost, create a lightweight job with the following criteria:

1. dbt compile

2. The option 'Generate docs on run' must be selected.

3. The job should be set to build the 'entire' data model or the specific part of the data model your organization wants to view in Euno.

Please note that while it's possible to use a lightweight job, it's not recommended. Since the job doesn't build the data model, it can't guarantee 100% accuracy. Therefore, if a lightweight job is created, it should be scheduled to execute regularly to ensure it reflects your warehouse transformations.

To configure the specific job for the project, click the "Select job" button under the "Deploy job link" heading on the project configuration page. This will open a dialogue box with a dropdown menu where a dbt job can be selected (see image below).

Configure dbt job

Connecting a New Branch

Connecting a new branch into a Euno project is a pivotal step in the evolution and collaboration of software development. This process not only extends the scope of the project but also introduces a new dimension of version control and collaboration. To connect a new branch, click the “Connect branch” button found in the top right corner of the project's Configuration tab, which will open a dialogue box to select a new branch to connect to.

Connecting a New Branch

Configuring the Data Application Sync

To leverage one of Euno's distinctive features, syncing your dbt changes back to your BI application, it is necessary to configure the specific data application for syncing with your dbt project.

Configuring LookML

From the project Configuration screen, users can link a specific branch in the project to a particular LookML file by clicking the "Sync to Data Application" button next to the branch. Clicking this button opens a dialogue box prompting you to input:

• LookML Repository

• Target branch

• Directory

• Selective sync

Configuring the Data Application Sync: Configuring LookML

Users can also specify whether they want the sync to be automatically committed to a branch (selected by default) or have Euno create a pull request.

Setting up this data sync ensures that with each new build from the selected job, Euno will automatically trigger a data application sync.

Customizing LookML Structure for Auto-code Generation

Euno uses Jinja2 templates to generate the LookML files from a given dbt manifest and catalog.

Out-of-the-box, every model that is selected by the tags (or all models, if no tags are specified), will automatically generate a single view file in the target directory. Users can customize the behavior by either specifying meta fields in the model or the column, or by overriding the default Euno Jinja2 macros.

Customizing Generated LookML by Specifying Meta Fields

Node Meta Fields

Meta key	Description	Default
getdelphi.io/lookml_filename	Full path of the resulting view file	./<model name>.view.lkml (The filepath needs to include the suffix for the file format)
getdelphi.io/lookml_sql_table_schema	Schema to use for the table	Schema specified in the manifest file
getdelphi.io/lookml_sql_table_name	Name of the table	Table name specified in the manifest file
getdelphi.io/lookml_view_name	Name of the view	Model name

Column Meta Fields

By default, Delphi will generate a single dimension clause for each column and a single measure for each dbt metric (MetricFlow).

Please note that only simple metrics and ratios are currently supported for dbt Metrics. In addition, we do not support metrics across multiple dbt models.

Meta field/Config key/Tag	Description	Default
getdelphi.io/lookml_label	Overrides lookml label for the field	No label
getdelphi.io/lookml_view_label	Overrides the lookml view the field is placed
getdelphi.io/lookml_group_label	Overrides the field in lookml group_label	No group label
getdelphi.io/lookml_hidden	Overrides the field in lookml hidden	Not hidden
getdelphi.io/lookml_value_format	Overrides the field in lookml value_format	No value format
getdelphi.io/lookml_value_format_name	Overrides the field in lookml value_format_name	No value format name
getdelphi.io/lookml_extra	For this specific key we expect users to insert a string with a lookml compliment fragment to be placed under the dimension or measure. For example "can_filter: yes"	No extra fields
getdelphi.io/lookml_tags	Overrides fields tags in the lookml file	Use the tags from the metric or column
getdelphi.io/lookml_sync_sql	Overrides the sql used for this dimension, or measure	For dimension - ${TABLE}.<column name> For measure: Simple - "expr" attribute of underlying measure in dbt Ratio - ${measure}/${measure}
getdelphi.io/lookml_sync_dimension_name	Only relevant for dimensions. Overrides the name of the dimension	Column name used
getdelphi.io/lookml_sync_measure_name	Only relevant for measures. Overrides the name of the measure	Measure name used
getdelphi.io/lookml_primary_key	Only relevant for dimension. Overrides the primary key of the dimension	The primary key of the column, if it exists
getdelphi.io/skip_lookml_sync	Set this tag to skip this column	The column/metric is included in the sync
getdelphi.io/lookml_sync_timeframes	Only relevant for time dimensions. Overrides the default timeframes for a timestamp or date column. This is a comma separated list of time grains.	raw, time, hour_of_day, date, day_of_week, week, month, quarter, year
getdelphi.io/lookml_sync_convert_tz	Only relevant for time dimensions. Overrides the default for converting by timezone.	The default is set to yes.

To configure any of the above options:

• For columns - Insert the meta key & and overriding value underneath the column in the YML file the model is found.

Example of Column with Meta Key

• For metrics - Insert the config key and overriding value in metric's YML file underneath the config key.

Example of Metric with Config Key

Customizing Generated LookML by Overriding Built-in Macros[

Euno will process any file in the dbt’s repository, under the directory .delphi/lookml_sync/macros/ as a Jinja2 template, and override any build-in macros found in those files.

Deploying LookML Changes Made in GitHub to Looker

Euno syncs to LookML any changes introduced to dbt, by utilizing the GitHub integration to commit changes directly to the LookML repository in GitHub. However, Looker does not automatically pull these changes from GitHub and deploy them to the production environment.

You have the option to deploy changes to the project's production environment in Looker either manually for every commit or by setting up automatic pushes from the master branch.

Note: This step is crucial to ensure a successful sync with Looker.

Manually

To manually deploy the changes from a branch to the Looker’s production environment, follow the following steps from within Looker:

• Enter “development mode”

• Go to “Develop”, and pick the Looker project

• Go to “Git Actions”

• Click “Pull from…” and pick “Pull from remote”

• Once the operation is done, click “Deploy to Production”

Automatically

Users can take advantage of Looker’s built-in Advanced deploy mode capability so that changes would automatically be deployed using either a webhook, API endpoint or manually using the deployment manager.

For Looker configurations involving GitHub, we can recommend configuring a webhook so that commits into the master branch would be automatically applied in Looker.

For more detailed instructions see Google’s instructions.

Project Home Screen

The Project Home screen is the landing page for the project. This includes two tabs; the "Overview" tab, and the "Configuration" tab.

Overview Tab

The Overview tab includes overview information about the project itself, including: the number of sources and models in the project, the connected branches, their health, and the health of the project.

Health

In the intricate landscape of data management, the concept of "health" transcends mere binary success or failure. In Euno, we introduce a nuanced understanding of health to provide users with comprehensive insights into the status and viability of their data builds and projects.

Build Health

In Euno, the health of a build refers to its current status and whether it has successfully progressed through the various stages of processing. Each build undergoes a lifecycle that includes uploading, processing, and being marked as processed. The health of a build is crucial for users who wish to explore the associated resources. Below are the different states of a build and their corresponding descriptions:

State	Description	Health
Uploading	Upload process ongoing, artifacts may take time	Pending
Upload incomplete	Upload process terminated before artifacts finished	Failed
Pending processing	Upload complete, waiting for a worker to process	Pending
Processing	A worker is processing the build	Pending
Processed	Build has been successfully processed	Success
Processed Failed	The build failed to process	Failed

The resulting build health helps users understand the current state of their builds, allowing for informed decision-making during exploration.

Project Health

Euno also provides insights into the overall health of projects, considering the health of both the main and side branches. The health of a project depends on the least healthy, active, side branch and the status of the main branch. Here are the different states and their implications for project health:

Health of Main Branch	Health of Least Healthy Active Branch	Project Health
Pending initial build	*	Pending initial build
Pending initial build	Healthy or Lagging	Healthy
Pending initial build, Healthy, or Lagging	Problem, or Error	Problem
Problem	*	Problem
problem	Error	Error

Understanding the project health helps users assess the overall stability of their projects, taking into account the health of both the main and side branches.

Project Health

Configuration Tab

The project configuration tab serves four primary functions in project management:

1. Administration of connected branches

2. Oversight of builds

3. Setting up data application synchronization

4. Configuring jobs for processing dbt builds

Project Configuration Tab

The builds section of this tab includes a list of builds, sorted chronologically by build time and date. This table includes the status of the build, and the data sync, if configured. Users can click on the status in order to view the details.

Builds Section of Project Configuration Tab