You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, if an erlang dep defined in the rebar.lockis not present on disk when a scan occurs, we silently ignore it. This is an artifact of the v1 implementation. This was never a problem for v1 because it almost always ran in a context immediately after a build, so all the deps were on disk via that build.
However, in the v2 implementation, there is no guarantee that the deps will be on disk when a scan occurs. This is the case in pre-merge CI, and if we are optimizing by only building on a subset of the packages that may have changed.
A workaround right now is to, before scanning, iterate through all your erlang apps and make sure to perform a full build before doing a scan.
The long term fix however is two-fold:
Support searching for the license based on the git_url provided by rebar_lock_json
Raise an error if we detect a dep in rebar lock, but can not find it on disk.
The text was updated successfully, but these errors were encountered:
Right now, if an erlang dep defined in the
rebar.lock
is not present on disk when a scan occurs, we silently ignore it. This is an artifact of the v1 implementation. This was never a problem for v1 because it almost always ran in a context immediately after a build, so all the deps were on disk via that build.However, in the v2 implementation, there is no guarantee that the deps will be on disk when a scan occurs. This is the case in pre-merge CI, and if we are optimizing by only building on a subset of the packages that may have changed.
A workaround right now is to, before scanning, iterate through all your erlang apps and make sure to perform a full build before doing a scan.
The long term fix however is two-fold:
git_url
provided byrebar_lock_json
The text was updated successfully, but these errors were encountered: