CORE-1273: migrate from Poetry to uv #2323
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -23,6 +23,10 @@ on: | |
| permissions: {} | ||
|
|
||
| env: | ||
| UV_VERSION: "0.12.3" | ||
| # Install into the interpreter provisioned by actions/setup-python, so that dbt and edr | ||
| # are invoked directly by the steps below. | ||
| UV_SYSTEM_PYTHON: "1" | ||
| BRANCH_NAME: ${{ github.head_ref || github.ref_name }} | ||
| ELEMENTARY_DBT_PACKAGE_PATH: ${{ github.workspace }}/dbt-data-reliability | ||
| E2E_DBT_PROJECT_DIR: ${{ github.workspace }}/elementary/tests/e2e_dbt_project | ||
|
|
@@ -57,16 +61,22 @@ jobs: | |
| with: | ||
| python-version: "3.10" | ||
|
|
||
| - name: Set up uv | ||
| uses: astral-sh/setup-uv@v7 | ||
| with: | ||
| version: ${{ env.UV_VERSION }} | ||
| enable-cache: true | ||
|
|
||
| - name: Install dbt | ||
| run: > | ||
| uv pip install | ||
| "dbt-core${{ inputs.dbt-version && format('=={0}', inputs.dbt-version) }}" | ||
| "dbt-snowflake${{ inputs.dbt-version && format('~={0}', inputs.dbt-version) }}" | ||
|
Comment on lines
70
to
74
There was a problem hiding this comment. 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
# Inspect the reusable workflow interface and its shell interpolation.
sed -n '1,90p' .github/workflows/test-github-action.yml
# Trace callers and determine whether dbt-version originates from trusted constants,
# validated workflow inputs, or branch-controlled values.
rg -n -C 6 --glob '*.yml' --glob '*.yaml' \
'uses:\s*(\./)?\.github/workflows/test-github-action\.yml|dbt-version:' \
.github/workflowsRepository: elementary-data/elementary Length of output: 9397 🏁 Script executed: #!/bin/bash
set -euo pipefail
printf '%s\n' '--- test-github-action.yml ---'
sed -n '1,110p' .github/workflows/test-github-action.yml
printf '%s\n' '--- test-warehouse.yml version handling ---'
rg -n -C 10 'dbt-version|pip install|validate|VERSION|^[[:space:]]*on:' \
.github/workflows/test-warehouse.yml
printf '%s\n' '--- all references to test-github-action.yml ---'
rg -n -C 8 --glob '*.yml' --glob '*.yaml' \
'test-github-action\.yml|test-github-action' .github
printf '%s\n' '--- workflow triggers and dispatch inputs ---'
rg -n -C 5 --glob '*.yml' --glob '*.yaml' \
'workflow_dispatch:|pull_request_target:|pull_request:|workflow_call:' .github/workflowsRepository: elementary-data/elementary Length of output: 16630 🏁 Script executed: #!/bin/bash
set -euo pipefail
python3 - <<'PY'
import subprocess
payload = '1.2"; echo INJECTED; #'
command = (
f'uv pip install '
f'"dbt-core=={payload}" '
f'"dbt-snowflake~={payload}"'
)
print('Generated command:')
print(command)
syntax = subprocess.run(
['bash', '-n'],
input=command + '\n',
text=True,
capture_output=True,
)
print(f'bash -n exit code: {syntax.returncode}')
if syntax.stderr:
print(syntax.stderr, end='')
print('Shell command segments:')
print(command.replace(';', '\\n;'))
PYRepository: elementary-data/elementary Length of output: 416 🌐 Web query:
💡 Result: For GitHub Actions workflows configured with the workflow_dispatch event, here is the breakdown of who can trigger them and how they interact with repository secrets: Who Can Trigger workflow_dispatch By default, any user with write access to the repository can manually trigger a workflow configured with the workflow_dispatch event [1]. As of June 2026, organizations and enterprises can implement more granular control through workflow execution protections [2]. These features allow administrators to define allow lists for specific actors (e.g., specific users, roles such as Maintainer or Admin, or GitHub Apps) and restrict which events are permitted, effectively allowing them to limit manual triggers to specific users or roles [2]. Triggering methods include the GitHub Actions UI, GitHub CLI, or the REST API [1]. For a workflow to be eligible for manual triggering via workflow_dispatch, the workflow file must be present on the default branch [3][1]. Access to Repository Secrets Workflows triggered via workflow_dispatch have access to repository-level secrets [4]. When a workflow runs, it can reference these secrets using the secrets context (e.g., ${{ secrets.MY_SECRET }}) [4]. There are specific conditions where secrets are restricted: - Forked Repositories: Secrets are generally not passed to the runner when a workflow is triggered from a forked repository [5][4]. - Reusable Workflows: If a workflow is called as a reusable workflow (even if it also supports workflow_dispatch), secrets are not automatically passed. They must be explicitly mapped or inherited using the secrets: inherit keyword in the caller workflow [4][6]. - Dependabot: Secrets are not available to workflows triggered by Dependabot events [4]. When triggering a workflow via workflow_dispatch from another workflow (programmatically), the triggering entity must use an authenticated token (such as a Personal Access Token or a GitHub App token) with sufficient permissions—typically actions: write on the target repository [7][8]. Citations:
Validate 🧰 Tools🪛 zizmor (1.29.0)[error] 73-73: code injection via template expansion (template-injection): may expand into attacker-controllable code (template-injection) [error] 74-74: code injection via template expansion (template-injection): may expand into attacker-controllable code (template-injection) 🤖 Prompt for AI AgentsSource: Linters/SAST tools
Contributor
There was a problem hiding this comment. Pre-existing, unchanged by this PR: only There was a problem hiding this comment.
|
||
|
|
||
| - name: Install Elementary | ||
| run: | | ||
| uv pip install --group dev | ||
| uv pip install ".[snowflake]" | ||
|
|
||
| - name: Write dbt profiles | ||
| env: | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -27,6 +27,11 @@ repos: | |
| - id: typos | ||
| exclude: index\.html$|elementary_output\.json$ | ||
|
|
||
| - repo: https://github.com/astral-sh/uv-pre-commit | ||
| rev: 0.12.3 | ||
| hooks: | ||
| - id: uv-lock | ||
|
|
||
|
Comment on lines
+30
to
+34
There was a problem hiding this comment. 🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift Choose one lockfile policy. If Either commit #!/usr/bin/env bash
set -euo pipefail
git ls-files --error-unmatch uv.lock
rg -n 'uv-lock|uv sync --locked' .pre-commit-config.yaml .github/workflows/run-precommit.yml🤖 Prompt for AI AgentsSource: MCP tools
Contributor
There was a problem hiding this comment. Already consistent as of There was a problem hiding this comment.
|
||
| - repo: local | ||
| hooks: | ||
| - id: no_commit | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -17,8 +17,10 @@ RUN apt-get update \ | |
| /var/tmp/* | ||
|
|
||
| COPY . /app | ||
| ARG UV_VERSION=0.12.3 | ||
| # --directory is what makes uv read /app/pyproject.toml, so the security floors in | ||
| # [tool.uv] constraint-dependencies apply to the image as well. | ||
| RUN pip install --no-cache-dir "uv==${UV_VERSION}" \ | ||
| && uv pip install --no-cache --system --directory /app ".[all]" | ||
|
|
||
| ENTRYPOINT ["edr"] | ||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
Repository: elementary-data/elementary
Length of output: 7163
🌐 Web query:
actions/dependency-review-action allow-dependencies-licenses PURL version matching documentation💡 Result:
In the GitHub Dependency Review Action, the
allow-dependencies-licensesconfiguration option allows you to exclude specific dependencies from license checks using the Package URL (PURL) format [1][2][3]. Regarding version matching and configuration behavior forallow-dependencies-licenses: 1. Version Handling: Unlike thedeny-packagesoption, which explicitly supports matching on exact versions (or acting as a wildcard if no version is provided) [2][3][4], the behavior ofallow-dependencies-licensestypically treats the provided PURL as a filter for that specific dependency [1]. If you provide a version in the PURL, it specifically targets that version; if no version is provided, it acts as a wildcard for that package [1]. 2. License-Specific Exclusions: As of February 2026, the action supports a more granular approach to exclusions using the?license=PURL qualifier [5]. This feature allows you to exclude a dependency only when it is associated with a specific license [5]. When no?licensequalifier is provided, the action preserves the previous wildcard behavior, excluding the dependency from license checks regardless of its license [5]. In summary, you can use standard PURL strings to exclude specific packages or versions [1][3]. For more precise control, you can append a?license=qualifier to your PURL entries in theallow-dependencies-licensesconfiguration to limit the exclusion to specific license conditions [5].Citations:
🏁 Script executed:
Repository: elementary-data/elementary
Length of output: 7398
🏁 Script executed:
Repository: elementary-data/elementary
Length of output: 50385
🏁 Script executed:
Repository: elementary-data/elementary
Length of output: 42534
🏁 Script executed:
Repository: elementary-data/elementary
Length of output: 803
Replace these broad exemptions with version-aware license validation.
allow-dependencies-licensesmatches only the PURL type and package name. It ignores the version. All six entries therefore permit any license for every version of each package. Adding a version to these PURLs does not scope the exemption.🤖 Prompt for AI Agents
Source: MCP tools
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Package-scoped is deliberate, and matches the three pre-existing entries. All three additions are false positives in the scanner, not licensing that varies by version:
metricflowhas been Apache-2.0 since 0.209.0 and the AGPL/BSL strings come from a historical note in its README;numpyfails only because the action doesn't decomposeBSD-3-Clause AND 0BSD AND MIT AND Zlib AND CC0-1.0, all of which are inallow-licenses;rapidfuzzis MIT with GPL headers in vendored FastFlow examples that aren't built into the wheel. Version-pinning them would just make the exemption expire on every bump and re-fail CI for the same non-issue.Note the
?license=qualifier you found isn't a fit either: it would allowlist e.g. AGPL-3.0 for that package, which is a strictly weaker statement than "this package's reported expression is a scan artifact", and it still isn't version-scoped. A genuinely GPL-only new dependency is still blocked, which is what the check is for.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.