[Bug] Using dbt deps on a git package with a branch name hardpins to the current branch commit

[rlh1994]

Is this a new bug in dbt-core?

• I believe this is a new bug in dbt-core
• I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior

When I use a branch name as the revision for a git package, as detailed in the docs https://docs.getdbt.com/docs/build/packages#git-packages, the package-lock.yml translates this to a hardpinned commit hash. When further commits are added to this branch, despite calling dbt clean and dbt deps again, this remains hard pinned to the earlier commit and I have to delete the package lock file to get it to fetch the latest commit on the branch instead.

Expected Behavior

I would expect it to find the latest commit hash for that branch and pull this. This is a common use case for testing and getting access to preview features.

Steps To Reproduce

1. Set up a dbt package with a branch named my_branch
2. Add this to a dbt project as a package using the git/revision structure, use revision my_branch
3. run dbt deps
4. Make a commit and push to the dbt package on my_branch
5. in your project, run dbt clean and dbt deps
6. Expand the dbt_packages folder, note that the change you made in your branch is not reflected here
7. Delete the package lock file
8. Repeat step 5+6, this time the change is there

Relevant log output

No response

Environment

- OS: MacOSX
- Python: 3.9.13
- dbt: 1.7.10

Which database adapter are you using with dbt?

No response

Additional Context

No response

[rlh1994]

This may be a regression not a bug, it maybe seems to be an extension/side effect of the behaviour that was agreed upon in the deps lock PR in particular:

Previously, running dbt deps will upgrade packages is version is specified as range and new version come out. For example, local package A is version 0.1.1, specified version [> 0.1.0, < 0.2.0]. Latest version is 0.1.5, running deps previously will install 0.1.5, but now with the lock file approach it will actually still install 0.1.1

While I find this behaviour a bit unexpected in general (given patch releases are often used to fix bugs, I would think the purpose of using a range would be to ensure you got the latest version...), I think in the case of a git branch this is even more unexpected, as I have specified a specific branch but the commit being used is no longer aligned with the actual head of the branch.

[rlh1994]

Sorry just reading through that PR a bit more, it seems like dbt deps --upgrade is the correct way to force an update.

I guess my question is why is this not the default behaviour so that it would have been a non-breaking change (and why isn't it listed as a breaking change in the changelog), and that I can't find this flag detailed anywhere in the docs https://docs.getdbt.com/docs/build/packages

[dbeatty10]

Thanks for reaching out about this and doing this research @rlh1994 ! 🙏

Good call that this this can be surprising so we should document this in both the migration guide for v1.7 and anywhere else it is applicable (like here or here).

Closing this issue in favor of updating the docs in dbt-labs/docs.getdbt.com#5140

[dom-devel]

A note to anyone who got here from Google. It's dbt deps --upgrade not update.

I found this thread reference above:

• [Core] Default behavior of dbt deps changed in v1.7 docs.getdbt.com#5140

The most useful for understanding the change.