Gemfile with dependabot-omnibus fails to install the dependabot-uv dep

[sobolevn]

Is there an existing issue for this?

• I have searched the existing issues

Package ecosystem

any

Package manager version

any

Language version

any

Manifest location and content before the Dependabot update

# frozen_string_literal: true

source "https://rubygems.org"

gem "dependabot-omnibus"

This is the Gemfile for the dependabot itself, not the one it is updating.
Here's how this file is installed:

.dependabot:
  image: ghcr.io/dependabot/dependabot-updater-$PACKAGE_MANAGER
  variables:
    PACKAGE_MANAGER: $CI_JOB_NAME
  retry: 1
  before_script:
    - bundle config set --local path 'vendor'
    - bundle install -j $(nproc)
  script: bundle exec ruby ./update.rb
  only:
    - schedules

pip:
  extends: .dependabot
  only:
    variables:
      - $PACKAGE_MANAGER_SET =~ /\bpip\b/

Link: https://github.com/wemake-services/kira-dependencies/blob/master/.gitlab-ci.yml

dependabot.yml content

No response

Updated dependency

No response

What you expected to see, versus what you actually saw

Downloading dependabot-omnibus-0.299.1 revealed dependencies not in the API
(dependabot-uv (= 0.299.1)).
Running `bundle update dependabot-omnibus` should fix the problem.
Cleaning up project directory and file based variables 00:00
ERROR: Job failed: exit code 1

Looks like dependabot-updater-pip (and maybe others) don't have this dependency for some reason.

Native package manager behavior

No response

Images of the diff or a link to the PR, issue, or logs

Related to #11687

Smallest manifest that reproduces the issue

No response

[sobolevn]

CC @markhallen

[eregon]

cc @deivid-rodriguez this sounds like a Bundler bug or maybe a something wrong in the state used for new API to me.

Also see ruby/setup-ruby#714 where apparently --full-index works around the issue.

[deivid-rodriguez]

Thank you. Yes @eregon is right, normally --full-index should normally not be necessary and when useful, there's generally a bug somewhere.

Can you elaborate a bit on how to reproduce this? The link you shared makes it sound like dependabot-script is being used, and that repo has a big "WARNING - Scripts are Currently Broken" in its README, so maybe that's related?

[Skenvy]

Not OP on this issue but basically;

1. bundle install on a gempsec that specifies dependabot-omnibus ver 0.299.0 works fine
2. bundle install on a gempsec that specifies dependabot-omnibus ver 0.299.1 fails with error (see)

   Downloading dependabot-omnibus-0.299.1 revealed dependencies not in the API
   (dependabot-uv (= 0.299.1)).
   Running `bundle update dependabot-omnibus` should fix the problem.
   

3. Using --full-index fixes it, and subsequent runs after don't need to specify --full-index again.
4. Running without --full-index with a Gemfile.lock already generated from successfully installing with --full-index locally, fails (both locally if the ruby installation is reset and in the bundle install run in the ruby/setup-ruby action if bundler-cache is set.

And I'm using the same version of ruby and bundler specified in dependabot-core (.ruby-version and Gemfile.lock's ~ bundled with).

[deivid-rodriguez]

Thank you! That link you shared seems like I should be able to repro and debug this by forking your repo and playing around with your CI, right?

[deivid-rodriguez]

Does the error still happen if you upgrade Bundler?

[Skenvy]

I can run it again later tonight to check, but yea, if you want to repro it, checkout the omnibus branch and the versions are lines 7-9 in the makefile. make install will expect rvm and nvm but I made it easy to avoid their use if someone needs to use it without them.