Articles in this section

See more

Materialize Git Repository flow

  • Updated
Follow

Overview

The Materialize Git Repository flow resolves a Git ref (branch, tag, or commit) to an exact commit and materializes a validated, read-only snapshot of the repository under the configured Git work root. It uses the same secure Git machinery as Git-backed dbt projects, exposed as a standalone flow.

Typical uses: fetch SQL scripts, configuration files, mapping documents, or a dbt project into Etlworks-managed storage so that other flows can use them, with the exact commit recorded for provenance.

The flow is intentionally read-only. It does not commit, push, merge, rewrite history, or author repositories.

Available in Etlworks 9.9.9 and later.

Create the flow

  1. Create a Git Repository connection for the repository and credentials.
  2. In the Flows window click + and type git. Select Materialize Git Repository.
  3. Select the connection in the required Git repository slot and configure the parameters.

Parameters

  • Destination Directory (required): relative directory under the Git work root (git.work.root, default {app.data}/git). Absolute paths and path traversal are rejected.
  • Git Ref: branch, tag, or commit to fetch (default HEAD). The resolved commit is recorded as GIT_COMMIT.
  • Repository Subdirectory: materialize only this subdirectory of the repository.
  • Replace Existing: atomically replace an existing destination after the new repository snapshot has been validated (default off).
  • Keep Log: include sanitized Git output in the Etlworks flow log (default on).
  • Execute if Error, On Exception, Disable manual flow execution: standard Etlworks flow behavior.

Bounds and settings

Materialization is bounded by account-level settings (Settings, Git section): Git Executable (default git), Git Work Root, Git Operation Timeout (default 5 minutes), Maximum Repository Size (default 1 GiB), and Maximum Repository Files (default 100,000). On an Integration Agent, the executable and work root come from the Agent parameters and resolve on the agent.

Security

  • Credentials come only from the Git Repository connection — never from the flow or the URL.
  • Git runs as an argument vector without a shell; HTTPS tokens use a private askpass mechanism, and SSH keys and known-host files are staged privately and removed afterward.
  • Destination containment and traversal are enforced; partial or invalid snapshots are never published.
  • Submodules and Git LFS are not silently enabled.

Related articles