Allow fetch-metadata to run on a PR even if it has additional commits…

[mwaddell]

…, as long as the 0th one was added by dependabot and is verified.

[phillipuniverse]

Just started seeing this on my PRs as well with the latest 1.2.1 on a PR that I had a new commit on top of:

Warning: It looks like this PR has contains commits that aren't part of a Dependabot update. Try using '@dependabot rebase' to remove merge commits or '@dependabot recreate' to remove any non-Dependabot changes.
Error: PR is not from Dependabot, nothing to do.

IMO the existing warning makes a lot of sense, very informative. Just would be nice to not error and instead ignore it. I see the conversation on #137 (comment) about it too.

For completeness, my GitHub action:

name: Dependabot auto-approve
on: pull_request_target
permissions:
  pull-requests: write

# From the docs at https://github.com/dependabot/fetch-metadata#enabling-auto-merge
jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: ${{ github.event.pull_request.user.login == 'dependabot[bot]' }}
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v1.2.1
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Auto-approve minor or patch updates
        if: |
          steps.metadata.outputs.update-type == 'version-update:semver-minor'
                || steps.metadata.outputs.update-type == 'version-update:semver-patch'
        run: gh pr review --approve "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

[brrygrdn]

Per discussion here, this check is highly defensive and it doesn't make sense to maintain it as it's causing friction in a lot of normal usage patterns, not least including just updating with the target branch via the UI.

Let's remove it as it's hindering more than it is helping.