How This Documentation Is Organized

This root page provides a cross-system overview, platform support matrix, core capabilities, user flow, and current limitations. Dedicated deep-dive pages exist for each system:

• GitHub Integration (Summary) — Full page: “VCS: GitHub Integration”

• GitLab Integration (Summary) — Full page: “VCS: GitLab Integration”

• Azure DevOps Git Integration (Summary) — Full page: “VCS: Azure DevOps Git Integration”

1. Overview

Ellie connects to your organization’s Git-based repositories to push model-generated artifacts (e.g., SQL from physical models and dbt YAML) directly from the Model page into a chosen repository, branch, and folder path. Users browse repositories/projects and branches, preview structure, and execute a commit-and-push workflow—without leaving Ellie.

• GitHub (Cloud and Enterprise Server) via GitHub App

• GitLab (Cloud and Self-Managed) via OAuth (Cloud only) or Access Tokens

• Azure DevOps Git (ADO) (Azure DevOps Services cloud)

2. Supported Platforms

3. High‑Level Capabilities

3.1 Connection Management (Admin Tools > Connectors)

• Create a new VCS connection from the Admin Tools > Connectors Page

• Choose the provider (GitHub, GitLab, ADO).

Open

• Authenticate using the supported method per provider.

Open

• Save connection at the organization level for reuse across Ellie.

Once created:

• The connection is stored and associated with the organization

• It can be used across the platform for repository operations

• Users can attach one or more default projects or repositories to the connection. This repository will then be preselected on the Model Page. 

Open

Open

• For each attached repository, users can also select a default branch. This branch will be preselected in the “Push to VCS” dialog. If the selected branch is protected, the dialog will display a notification indicating that it cannot be used for write operations.

Open

• If a preselected branch is protected, Ellie displays a notification that it cannot be used for write operations.

3.2 Repository / Project Discovery

• Fetch available repositories (GitHub) or projects (GitLab, ADO).

• View accessible branches for the selected target.

• Browse the repository tree (folder/file structure).

• Retrieve branch content context before writes.

This enables Ellie to understand the structure of the target repository before performing any write operations.

3.3 Branch & Repository Tree Access

For a selected repository/project, Ellie supports:

• List branches and preselect the configured default branch (if set).

• Select target branch; protected branches warn on write restrictions.

• Read tree structure for the selected branch and navigate folders/paths.

4. Model-Based File Generation & Push

From the Model page, users can:

• Generate model-based files, including:

  • SQL files (physical models)

  • dbt YAML configuration files (all model levels)

Open

• Select:

  • Target repository/project

  • Target branch

  • Target folder/path

Open

• Create a commit and push changes directly to the selected branch.

Push workflow includes:

• file generation from model definitions,

• file creation in the chosen folder,

• commit creation

• push to the target branch.

This enables a seamless, version-controlled workflow anchored in Ellie.

5. Typical User Flow

1. Admin creates a VCS connection (GitHub, GitLab, or ADO).

2. User opens the Model page.

3. User generates SQL and/or dbt YAML files.

4. User selects repository/project, branch, and target folder.

5. User confirms push.

6. Ellie commits and pushes to the selected branch.

6. Current Scope & Limitations (v2.0)

Included focus areas:

• Secure repository connectivity

• Branch access and tree browsing

• Model-driven file generation (SQL, dbt YAML)

• Commit and push

Not included in v2.0 (candidates for future releases):

• Pull/Merge Request creation

• Advanced branch management

• Webhook synchronization

• CI/CD pipeline integration (no direct pipeline triggering from Ellie; pipelines can still be triggered externally via repository changes)

• Conflict resolution workflows

• UI for repository write-permissions validation

7. System Summaries (Deep-Dives Linked)

8. Best Practices

9. Security Considerations

• Server-to-server authentication used where possible (GitHub App model; short-lived installation tokens).

• GitLab requires api scope because operations are performed via REST API (not raw Git alone).

• Tokens, app keys, and installation IDs are stored securely and used to generate time-bound access for API calls.