"failed to parse title: could not detect dependency name"

[peterbe]

using workflow's "target": 
- match:
    dependency_type: all
    update_type: 'semver:minor'

title: "Update actions/setup-node requirement to v2.1.2"
depName: undefined
Warning: failed to parse title: could not detect dependency name

Here's the failing auto-merge run Here's the PR itself

That depName: undefined looks suspiciously like a bug and the PR itself is pretty sane. So perhaps the mistake is that the it bailed and just did a warning.

[iranzo]

Just was testing this action and hit this same exact error :/

[iranzo]

@ahmadnassri is there something wrong in our config yaml or in the code for the action itself? Thanks!

[ahmadnassri]

yes, this looks like the regex for the dep name is failing ...

the traditional dependabot PRs are usually titled: "update x from y to z"

though, in your example it came through as "update xxx requirement to z"

this is ... new to me, any clue why the dependabot PR came in like that?

[ahmadnassri]

@iranzo do you have a link to your example? wondering if this is a fluke from dependabot side...

[ahmadnassri]

looking at github search, there are quite a few examples, though the addition of the word "requirement" is consistant (easy fix) the "from" version string is missing in some ... very interesting, and likely a bug on dependabot ...

https://github.com/search?q=Update+requirement+to+author%3Aapp%2Fdependabot&type=issues

I'll see if we can make some workarounds, though expect different behaviour in this case since we don't have a "previous version" to compare to, and thus some of the match logic will be incompatible (except of course "all")

[iranzo]

I got it at github.com/iranzo/gh-action-runpublish

Sorry I am away from keyboard and can't provide url now

[ahmadnassri]

@iranzo i found it, thanks make some fixes / tests now

[iranzo]

@iranzo i found it, thanks make some fixes / tests now

Let me know if you want me to test it, thanks!

[github-actions[bot]]

:tada: This issue has been resolved in version 2.1.3 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket:

[ahmadnassri]

@iranzo @peterbe fixes have been pushed and updated, also a new section to the README has been added to discuss some of those edge-cases: https://github.com/ahmadnassri/action-dependabot-auto-merge#exceptions-and-edge-cases

let me know if this makes sense and if the new version fixes the issue.

thank you.

[peterbe]

I'll test to rebase my Dependabot PRs that failed once Dependabot upgrades action-dependabot-auto-merge itself.

[peterbe]

Still no luck. :( See https://github.com/mdn/yari/pull/1395/checks?check_run_id=1264500764

 using workflow's "target": 
- match:
    dependency_type: all
    update_type: 'semver:minor'

title: "Update actions/setup-node requirement to v2.1.2"
depName: actions/setup-node
from: unknown
to: 2.1.2
dependency type: production
security critical: false
config: all:semver:minor
Warning: no version range detected in PR title
manual merging required

I rebased the pull request about an hour ago. In that tree, you can see that it uses ahmadnassri/action-dependabot-auto-merge@v2.1.4

[ahmadnassri]

this is now working as expected @peterbe

• the pull request doesn't have a "from" version in the title
• dependabot seems to do that sometimes, can't discern the logic or pattern behind it
• since there is no "from" and your config indicated a target of "semver:minor", there is no way to calculate if the PR is within that target range
• the action used to fail before, but now is handling this edge case and displaying an appropriate warning with a soft exit

short of this action going full into parsing every dependency package definition file or reading the PR diff and determining which version did dependabot try to update... I can't think of a work around here

[peterbe]

Ah! Of course. Now I can see what you mean. So unless we parse the diff we can't figure out what the previous version number was. Dang, that's not feasible. So, do we need to pester GitHub (their Dependabot "department") to claim it's a bug to not mention the from-version in the PR title?

[ahmadnassri]

@peterbe definitly need more pstering towards GH ...

it would be great if they expose an API so we can do this better without the magic of regexes and parsing text!

[ahmadnassri]

also see #34

[iranzo]

Got it working for some pr's but also failed in one without 'from', a pity :) thanks for the fix for the other use-case

[ahmadnassri]

I opened an issue here with dependabot, hopefully they respond: https://github.com/dependabot/dependabot-core/issues/2659

[ahmadnassri]

@iranzo @peterbe I've been experimenting with dependabot configuration after running into more issues where dependabot was not opening up consistent PR titles, namely it was opening a chore(dep):.... instead of a build(dep): ....

tl;dr force the naming convention by setting commit-message` in dependabot config: specifically:

    commit-message:
      prefix: build
      prefix-development: chore
      include: scope

see live example here: https://github.com/ahmadnassri/action-dependabot-auto-merge/blob/0da6f4fddfe74567485cbbcdb4b6f28e19f6f4ea/.github/dependabot.yml#L6-L9

this might help with the inconsistent PR titles

[peterbe]

this might help with the inconsistent PR titles

Ok. So it's early days, but I'm willing to try.

[ahmadnassri]

@peterbe yeah, hard to test and validate this...

I did try it on a repo that had an open PR with the wrong title, then did a dependabot recreate and it did in fact recreate a new PR with the right title ... but that was a one-off ...

[iranzo]

@peterbe yeah, hard to test and validate this...

I did try it on a repo that had an open PR with the wrong title, then did a dependabot recreate and it did in fact recreate a new PR with the right title ... but that was a one-off ...

Does that mean that you need more 'validations' to consider it ok? I don't mind adding that to all the repos I've access too and see when dependabot triggers again... but that might take time

[ahmadnassri]

for my part, I added it on all 80+ repos in my public GitHub and 100+ in private company repos ...

1. no issues causes
2. consistently producing the correct titles (20+ PRs came in overnight and got auto merged)

my comment about a "one off" was specifically when I told dependabot to recreate it resulted in actually recreating the PR with the correct title ...

before the config change, wrong type chore for a prod dep:

applied the config change and asked dependabot recreate:

it closes the PR and made a new one with the correct type build:

while this example doesn't have the "missing from x.y.z" issue, it demonstrates that dependabot config seems better enforceable with these settings