Skip to content

Conversation

@myronmarston
Copy link
Collaborator

Being limited to 5 at a time is having a productivity impact since we're behind on depndency upgrades. And I don't generally want dependabot PRs to be limited (so long as it's not an absurd number of them...).

Being limited to 5 at a time is having a productivity impact
since we're behind on depndency upgrades. And I don't generally
want dependabot PRs to be limited (so long as it's not an
absurd number of them...).
@CLAassistant
Copy link

CLAassistant commented Jul 8, 2025

CLA assistant check
All committers have signed the CLA.

Copy link
Collaborator

@BrianSigafoos-SQ BrianSigafoos-SQ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@myronmarston myronmarston merged commit 9c95fcc into main Jul 8, 2025
16 of 17 checks passed
@myronmarston myronmarston deleted the myron/more-dependabot-prs branch July 8, 2025 20:26
myronmarston added a commit that referenced this pull request Jul 8, 2025
This reverts commit 9c95fcc.

Since merging that change, Dependabot has begun failing with:

> Dependabot can't update vulnerable dependencies without a lockfile
> The currently installed version can't be determined.
>
> To resolve the issue add a supported lockfile (Gemfile.lock or gems.locked).

Example: https://github.com/block/elasticgraph/actions/runs/16154309990/job/45593081085

I don't understand the failure (we ahve a `Gemfile.lock`!) but since the
failure only started when I edited `.github/dependabot.yml`, I'm reverting
it.
myronmarston added a commit that referenced this pull request Jul 8, 2025
This reverts commit 9c95fcc.

Since merging that change, Dependabot has begun failing with:

> Dependabot can't update vulnerable dependencies without a lockfile
> The currently installed version can't be determined.
>
> To resolve the issue add a supported lockfile (Gemfile.lock or gems.locked).

Example: https://github.com/block/elasticgraph/actions/runs/16154309990/job/45593081085

I don't understand the failure (we ahve a `Gemfile.lock`!) but since the
failure only started when I edited `.github/dependabot.yml`, I'm reverting
it.
myronmarston added a commit that referenced this pull request Jul 8, 2025
This partially reverts "chore: rework Gemfiles. (#645)" (cce2474).
It recombines the root `Gemfile` with `config/Gemfile-for-gem`, doing away with `Gemfile-shared`,
while keeping the changes to #645 that impact how the root bundle works (e.g. calling `gem`
with each ElasticGraph gem, rather than `gemspec`).

This appears to be necessary for dependabot. While some dependabot runs have been successful
since #645 was merged, the last few runs have failed with:

```
Handled error whilst updating rubocop-rake: dependency_file_not_supported {message: "{\"errors\":[{\"status\":400,\"title\":\"Bad Request\",\"detail\":\"The request contains invalid or unauthorized changes\"}]}"}
```

I think the problem is `Gemfile-shared`: it's non standard to put gem
versions there, and dependabot seems to not like it. By reverting back
to a single root `Gemfile` I'm hopeful it'll fix dependabot.

In addition, I've reapplied "Increase the dependabot open-pull-request-limit. (#657)", effectively reverting (#659).
That was a prior attempt at fixing dependabot which didn't work.
myronmarston added a commit that referenced this pull request Jul 9, 2025
This partially reverts "chore: rework Gemfiles. (#645)" (cce2474).
It recombines the root `Gemfile` with `config/Gemfile-for-gem`, doing away with `Gemfile-shared`,
while keeping the changes to #645 that impact how the root bundle works (e.g. calling `gem`
with each ElasticGraph gem, rather than `gemspec`).

This appears to be necessary for dependabot. While some dependabot runs have been successful
since #645 was merged, the last few runs have failed with:

```
Handled error whilst updating rubocop-rake: dependency_file_not_supported {message: "{\"errors\":[{\"status\":400,\"title\":\"Bad Request\",\"detail\":\"The request contains invalid or unauthorized changes\"}]}"}
```

I think the problem is `Gemfile-shared`: it's non standard to put gem
versions there, and dependabot seems to not like it. By reverting back
to a single root `Gemfile` I'm hopeful it'll fix dependabot.

In addition, I've reapplied "Increase the dependabot open-pull-request-limit. (#657)", effectively reverting (#659).
That was a prior attempt at fixing dependabot which didn't work.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants