dbt packages.yml with no package-lock.yml

This rule flags a dbt project whose packages.yml or dependencies.yml has no package-lock.yml beside it. It passes if every package is pinned exactly: one version, a commit SHA, a version tag or a local path. Version ranges, git branches and packages with no version float, and we name those. Only the root-most dbt project is judged.

Package versions resolve fresh on every install. Two CI runs a week apart can build the same project against different package code. A macro can change behaviour with nothing in the repository's history to show it.

Commit the dbt package lockfile. Commit the package-lock.yml that dbt deps already writes, and change it only on purpose.

Before:

# packages.yml, with no package-lock.yml beside it
packages:
  - package: dbt-labs/dbt_utils
    version: [">=1.0.0", "<2.0.0"]

After:

# package-lock.yml, written by dbt deps and committed
packages:
  - package: dbt-labs/dbt_utils
    version: 1.3.0
sha1_hash: <written by dbt deps>

A project that pins every package to one exact version already passes, because it resolves the same way each time. Another sub-project in the repository, such as integration_tests/, is named in the finding as not examined.

The repository's file list, the packages file, and the dbt version from manifest.json. package-lock.yml exists from dbt 1.7, so without a manifest we decline, and older projects are not judged. We also decline if the listing was truncated or the packages file could not be read. If it was not fetched at all, we report the missing lockfile without judging the pins.