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
What you expected to see, versus what you actually saw
This is a copy of an issue that was closed recently.
Dependabot created a PR fixing some vulnerability, and as per #7744, we saw a new behaviour where it included an index called dependabot-inserted-index-0 in some of the transitive dependencies in our Pipfile.lock, for example:
It added that index to packages that were updated, but also to some that were not updated. It didn't add the index to all the packages. See diff below:
Our build pipelines were able to sync the dependencies when they were using an old version of pipenv, for example v2022.1.8 (we haven't found which version is the newest that still works):
Successfully installed pipenv-2022.1.8
..........................................................................................................
·✔ Successfully created virtual environment!
--
179 | Virtualenv location: /root/.local/share/virtualenvs/authorizer-0svWqLcN
180 | Installing dependencies from Pipfile.lock (923e0b)...
181 | To activate this project's virtualenv, run pipenv shell.
182 | Alternatively, run a command inside the virtualenv with pipenv run.
183 | All dependencies are now up-to-date!
However, when we updated to the latest version of pipenv (v2023.8.28), we encountered this error:
We are trying to reproduce locally using the Dependabot CLI as requested in #7936 (comment), but we are unable to authenticate the dependabot CLI against our private CodeArtifact repository: dependabot/cli#196
Reopening this to hopefully get assistance reproducing this issue with the CLI.
Thanks!
Native package manager behavior
After manually updating the dependencies with the latest version of pipenv, that index added by dependabot disappeared and our build pipelines were able to sync again. This is the change after doing a pipenv update manually:
Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue
No response
The text was updated successfully, but these errors were encountered:
Is there an existing issue for this?
Package ecosystem
pipenv
Package manager version
No response
Language version
python 3.9
Manifest location and content before the Dependabot update
No response
dependabot.yml content
We have a private repo where we pull all our dependencies from:
Updated dependency
No response
What you expected to see, versus what you actually saw
This is a copy of an issue that was closed recently.
Dependabot created a PR fixing some vulnerability, and as per #7744, we saw a new behaviour where it included an index called dependabot-inserted-index-0 in some of the transitive dependencies in our Pipfile.lock, for example:
It added that index to packages that were updated, but also to some that were not updated. It didn't add the index to all the packages. See diff below:
Our build pipelines were able to sync the dependencies when they were using an old version of
pipenv
, for examplev2022.1.8
(we haven't found which version is the newest that still works):However, when we updated to the latest version of
pipenv
(v2023.8.28
), we encountered this error:We are trying to reproduce locally using the Dependabot CLI as requested in #7936 (comment), but we are unable to authenticate the dependabot CLI against our private CodeArtifact repository: dependabot/cli#196
Reopening this to hopefully get assistance reproducing this issue with the CLI.
Thanks!
Native package manager behavior
After manually updating the dependencies with the latest version of pipenv, that index added by dependabot disappeared and our build pipelines were able to sync again. This is the change after doing a pipenv update manually:
Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue
No response
The text was updated successfully, but these errors were encountered: