I adjusted my workflow to take advantage of this change, but now it fails if I add commits to to the PR.

Typical reasons for this would be to add an entry to the changelog, fix linting rules, or as happened today fix an incorrect version update (a couple actions used v2 instead of v2.0.0).

What's the best way to work around this? Maybe a new output indicating if non-dependabot commits were found so you could skip subsequent steps?

@brrygrdn What's the reason for failing the run if the PR contains commits after the original dependabot one? Is there a good reason not to delete https://github.com/dependabot/fetch-metadata/blob/main/src/dependabot/verified_commits.ts#L35:L38

@brrygrdn What's the reason for failing the run if the PR contains commits after the original dependabot one? Is there a good reason not to delete https://github.com/dependabot/fetch-metadata/blob/main/src/dependabot/verified_commits.ts#L35:L38

@brrygrdn - I added #166 to remove those lines in order to address the issue noted by @xt0rted - let me know if there's a reason we can't do this.

That's a good question, it's something I've actually been blocked by myself this week. I originally added it as we were (defensively) trying to facilitate narrowest possible definition of a Dependabot PR, i.e.

• Created by Dependabot
• Exclusively containing code committed by Dependabot

I don't think any potential benefit or risk it mitigates really offsets the fact that an extremely common workflow like merging in the target branch is blocked. I'll have a chat with the team on Monday morning to get a second opinion, but I'm leaning towards removing this.