Hi,

I've tried this action today and am very happy to have created this workflow with it :)
One thing that made the creation a bit complicated for me was that the new-version contained a trailing newline as can be seen in this action run:

The output of

    - name: Log some stuff
      run: |
        echo "Line One"
        echo "${{ steps.dependabot-metadata.outputs.previous-version }}"
        echo "Line Two"
        echo "${{ steps.dependabot-metadata.outputs.new-version }}"
        echo "Line Three"
        echo "Line One"
        echo "${{ steps.version-numbers.outputs.previous-version }}"
        echo "Line Two"
        echo "${{ steps.version-numbers.outputs.new-version }}"
        echo "Line Three"

(the version-numbers step is my manual approach of stripping the whitespaces) is

  echo "Line One"
  echo "0.23.3"
  echo "Line Two"
  echo "0.24.1
  "
  echo "Line Three"
  echo "Line One"
  echo "0.23.3"
  echo "Line Two"
  echo "0.24.1"
  echo "Line Three"

I'm not sure if this problem is specific to the pip ecosystem and/or may also happen for previous-version, but it would be nice if fetch-metadata could strip leading and trailing whitespaces automatically :)

Cheers,
Hinrich

Not sure whether something changed on dependabot end, but fetching metadata suddenly fails since earlier today, observed on all three dependabot pull requests we received today:

Run dependabot/[email protected]
  with:
    github-token: ***
Parsing Dependabot metadata
Error: PR does not contain metadata, nothing to do.

E.g. here: https://github.com/ravenclaw900/DietPi-Dashboard/actions/runs/2028340724

Probably related to today's core release? dependabot/dependabot-core#4898

@yeikel pointed out that we don't need to do the internal check within the action if we recommend on the Readme that users check the user before executing the action:

• #317 (comment)
• #331 (comment)

I think this is the reason the check exists within the code... the concern is that users may not realize they need to set that, and so may fire off spurious requests... so it's defensive coding to protect the API from ignorant/careless users.

That said, I agree the volume of calls here is probably pretty low, so it may be fine to remove this... 🤷‍♂️

Removing it would simplify the code / config complexity since the DEPENDABOT_LOGIN const and associated logic of letting users customize the user simply disappears...

Currently, unlike with other GitHub actions, it is not possible to use the latest v1 via:

uses: dependabot/fetch-metadata@v1

=>

Error: Unable to resolve action `dependabot/fetch-metadata@v1`, unable to find version `v1`

It would be great it that was possible, so one does not need to (or gets offered to) update the workflow on every patch or minor version, where maintained compatibility is at least expected. Similarly dependabot/[email protected] would be nice to work for a more conservative approach, pulling the latest patch version only.

I know this works with the official GitHub Actions actions, like actions/checkout@v3. They create and update additional release tags for this: https://github.com/actions/checkout/tags

It would be great to be able to say "merge minor bumps that has a compatibility score greater than 90%" as part of an automated merge.

According to https://github.blog/changelog/2022-04-06-dependabot-alert-api-adds-relevant-update-info-to-the-schema, dependabot alerts are now easily connected to the relevant pull requests.

I was wondering if you are considering leveraging this new feature to simplify the work that had been done here before.

Cheers

I am using "dependabot/fetch-metadata" v1.2.1 but I am often receiving an error message that it cannot automatically merge PRs:

Enable auto-merge for Dependabot PRs

Run gh pr merge --auto --squash "$PR_URL"
Message: Can't enable auto-merge for this pull request., Locations: [{Line:[1](https://github.com/southpolecarbon/alaska/runs/5287794531#step:3:1) Column:[7](https://github.com/southpolecarbon/alaska/runs/5287794531#step:3:7)2}]
Error: Process completed with exit code 1.

Am I missing something in my workflow to make it work?

name: Dependabot auto-merge
on: pull_request_target

permissions:
  pull-requests: write
  contents: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: ${{ github.actor == 'dependabot[bot]' }}
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/[email protected]
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
      - name: Enable auto-merge for Dependabot PRs
        run: gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Based on https://github.com/dependabot/fetch-metadata#:~:text=The%20type%20of%20dependency%20has%20determined%20this%20PR%20to%20be%2C%20e.g.%20direct%3Aproduction.%20For%20all%20possible%20values%2C%20see%20the%20allow%20documentation., it seems one can go to https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates#allow to see a list of all supported values for dependency-type. But I could not see that direct:production is a possible value as per the provided example. The allow option only lists the following:

• direct
• indirect
• all
• production
• development

Should there be a documentation section for the possible values of dependency-type in this current repository?

Thanks!

We'd like to be able to label / prevent auto-merge on PRs where the release was published to NPM by a new maintainer. This would allow us to do a manual security review and probably wait a bit to ensure permissions to publish wasn't granted to a bad actor.

Description

I am using the dependabot/fetch-metadata action (v1.3.6) in my workflow to handle Dependabot pull requests. However, I am encountering an issue where the update-type output is returning null, even though the pull request is created by Dependabot.

Repository Configuration

Here's the dependabot.yml configuration for the repository:

version: 2

updates:
  - package-ecosystem: pip
    directory: /dependabot/
    schedule:
      interval: "weekly"
      day: "sunday"
    commit-message:
      prefix: "build: "
      prefix-development: "build: "
      include: "scope"
    rebase-strategy: "auto"
    target-branch: "develop"
    labels:
      - "build"
      - "dependencies"
    versioning-strategy: auto
    allow:
      - dependency-type: "all"
    open-pull-requests-limit: 10

The pyproject.toml file is located in the /dependabot/ directory, which is specified in the dependabot.yml configuration

Workflow Configuration

The following is the configuration for the workflow that uses the dependabot/fetch-metadata action:

on:
  pull_request_target:
    types:
      - opened
      - synchronize
permissions:
    pull-requests: write
    contents: write
jobs:
  review-dependabot-pr:
    runs-on: ubuntu-latest
    if: ${{ github.event.pull_request.user.login == 'dependabot[bot]' }}
    outputs:
      approved: ${{ steps.set-output.outputs.approved }}
    steps:

        # ... (other steps)

        - name: 📛 Dependabot metadata
            id: dependabot-metadata
            uses: dependabot/[email protected] # https://github.com/dependabot/fetch-metadata
            with:
                github-token: "${{ steps.generate_token.outputs.token }}"

        # ... (subsequent steps using the outputs)

Issue Details

When the workflow runs for a pull request created by Dependabot, the action returns a null update-type output, which causes issues in the subsequent steps that rely on this output.

Here's an example of the outputs returned by the dependabot/fetch-metadata action:

##[group]Run dependabot/[email protected]
with:
  github-token: ***
  skip-commit-verification: false
##[endgroup]
Parsing Dependabot metadata
##[group]Outputting metadata for 1 updated dependency
outputs.dependency-names: pytest
outputs.dependency-type: direct:development
outputs.update-type: null
outputs.directory: /dependabot/develop
outputs.package-ecosystem: pip
outputs.target-branch: develop
outputs.previous-version: 
outputs.new-version: 
outputs.compatibility-score: 0
outputs.alert-state: 
outputs.ghsa-id: 
outputs.cvss: 0
##[endgroup]

The issue persists even after verifying that the pull request is created by Dependabot and that the workflow is triggered by the correct event (pull_request_target with opened and synchronize types).

Request for Assistance

I would appreciate any help in diagnosing and resolving this issue. If there's any additional information or logs that would be useful, please let me know, and I will provide them.

In dependabot.yml, package-ecosystem for submodules is gitsubmodule. When output by this action, the result is just submodules. Since the package ecosystem is documented to be:

The package-ecosystem configuration that was used by dependabot for this updated Dependency.

The output should be made consistent with what is declared in the yml file.

Example workflow where this took place: https://github.com/hpackage/hpackage-rs/actions/runs/4902525037/jobs/8754565816

I am currently running dependabot-script in a private GHE instance to generate pull requests for my projects

I would like to leverage this project but this check :

Expects the sender of the PR to be 'dependabot[bot]' when that's not possible within my context

Would you be open to adding an optional configuration parameter to the action to allow customizing this value?

As a side note, most Action examples suggest this as an optimization :

if: ${{ github.event.pull_request.user.login == 'dependabot[bot]' }}

I am willing to send a PR with the same

See #334 (comment)

Updating the dist manually is a hassle. I'd be nice if we had some sort of automation to update the pull request Dist when there are new changes

It'd be nice to have a .devcontainer in this project as the default devcontainer starts with a much higher version of Node and NPM

The external_identifier field contains the CVE-ID, which should be quite easy to include in this action. Did I miss it or has this not (yet) been implemented? Thanks!

We need a way to block pre-1.0.0 semver patch bumps. Ideally, we'd have extra metadata available to us to allow us to easily do this via

${{steps.metadata.outputs.version.major >= 1 && steps.metadata.outputs.update-type == 'version-update:semver-patch'}}

Having the alert number linked to the PR could be really useful when trying to get about the alert through the GitHub REST API

We've been using the dependabot/fetch-metadata action for a short time, referencing the v1 tag in our workflows:

    - name: Dependabot metadata
      id: dependabot-metadata
      uses: dependabot/fetch-metadata@v1

Today we started seeing multiple workflow failures, each reporting the following error:

Download action repository 'dependabot/fetch-metadata@v1' (SHA:90ed90dba204fdf8970c1f891b4349c96353f220)

Error: dependabot/fetch-metadata/v1/action.yml:
Error: dependabot/fetch-metadata/v1/action.yml: (Line: 18, Col: 113, Idx: 682) - (Line: 18, Col: 141, Idx: 710): While parsing a block mapping, did not find expected key.
Error: System.ArgumentException: Unexpected type '' encountered while reading 'action manifest root'. The type 'MappingToken' was expected.
   at GitHub.DistributedTask.ObjectTemplating.Tokens.TemplateTokenExtensions.AssertMapping(TemplateToken value, String objectDescription)
   at GitHub.Runner.Worker.ActionManifestManager.Load(IExecutionContext executionContext, String manifestFile)
Error: Fail to load dependabot/fetch-metadata/v1/action.yml

Comparing v1.3.1 against v1.3.2, I can see that "(Line: 18, Col: 113, Idx: 682) - (Line: 18, Col: 141, Idx: 710)" refers to the description attribute of the new skip-commit-verification option introduced by v1.3.2:

  skip-commit-verification:
    type: boolean
    description: 'If true, the action will not expect Dependabot commits to be verified. This should be set as 'true' in GHES environments.'
    default: false

Column 113 marks the single-quotation at the start of 'true' in GHES environments.. This is invalid YAML syntax - as the entire string is surrounded by single-quotes.

v1.3.1...v1.3.2

Workaround

Changing our workflow to specify v1.3.1 has temporarily resolved the issue for us:

    - name: Dependabot metadata
      id: dependabot-metadata
      uses: dependabot/[email protected]

Instead of using on: pull_request_target we would like to run as a cron:

on:
  schedule:
  - cron: '*/30 4-7 * * 1-4'

So it only merges during dawn and doesn't get in the way of our devs.

Does this configuration work?
If not would it be possible to change the action to have the pull request number (or url)?

I'm using this action to auto-merge https://github.com/dependabot/fetch-metadata#enabling-auto-merge and it's working fine except that the other workflows that are normally triggered on merge to main are not triggered.

I'm pretty sure it's because secrets.GITHUB_TOKEN is used https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#triggering-new-workflows-using-a-personal-access-token but then I guess I don't understand this use case if I need to use a PAT to have the "normal" behavior.

Am I getting this wrong?

The README says we should get dependency-type info like direct:production, which conveys information along two axes: direct/indirect and production/development. But in our PRs, I'm just seeing e.g. indirect as the only type information, which makes it hard for us to do things like "auto-merge any development dependency update."

Would it be possible to change this so it always has both pieces of information?

Our workflow file for auto-merging dependabot PR is below:

name: Auto-Merge Dependabot PR
on:
  pull_request:
    branches: ['development']

permissions:
  pull-requests: write
  contents: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: ${{ github.actor == 'dependabot[bot]' }}
    steps:
      - name: Checkout source code
        uses: actions/checkout@v3

      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v1
        with:
          github-token: '${{ secrets.DEPENDABOT_GITHUB_TOKEN }}'

      - name: Approve PR
        run: gh pr review --approve "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GITHUB_TOKEN: ${{ secrets.DEPENDABOT_GITHUB_TOKEN }}

      - name: Enable auto-merge for Dependabot PRs
        run: gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GITHUB_TOKEN: ${{secrets.DEPENDABOT_GITHUB_TOKEN}}

We use the same workflow in a dozen of repos, and it works well.
But, we see below error in only two repos, even though there's no difference in the workflow file(just copy-pasted), and the DEPENDABOT_GITHUB_TOKEN is an org secret.

Run dependabot/fetch-metadata@v1
  with:
    skip-commit-verification: false
    skip-verification: false
Error: github-token is not set! Please add 'github-token: "${{ secrets.GITHUB_TOKEN }}"' to your workflow file.

How can it be possible, and what could be the root cause?

EDIT: As I tried to set this up in more repos, the same thing happens even after a few successful auto-merges. So it works and then stops to work showing the above error with no clue. No changes applied to the workflow or anything else in the repo.

If you look at https://github.com/SalimBensiali/le-blanc-jewellery/runs/5561937034?check_suite_focus=true, you would expect to see the relevant vulnerability alert metadata, but I am always getting the default data instead, ie:

outputs.alert-state: ''
outputs.ghsa-id: ''
outputs.cvss: 0

• I am using a PAT with enough permissions for successful GraphQL API calls
• I have double checked that the PR is indeed fixing a security vulnerability SalimBensiali/le-blanc-jewellery#215

To allow configuring the Github auto-merge for certain types of package-ecosystems and directory only I would like to get this included as well.

So e.g. the following could be added to the outputs:

  package-ecosystem: "github-actions"
  directory: "/"

Dependabot just attempted to update this action for me and the jobs are failing with:

Error: dependabot/fetch-metadata/v1.3.2/action.yml:
Error: dependabot/fetch-metadata/v1.3.2/action.yml: (Line: 18, Col: 113, Idx: 682) - (Line: 18, Col: 141, Idx: 710): While parsing a block mapping, did not find expected key.
Error: System.ArgumentException: Unexpected type '' encountered while reading 'action manifest root'. The type 'MappingToken' was expected.
   at GitHub.DistributedTask.ObjectTemplating.Tokens.TemplateTokenExtensions.AssertMapping(TemplateToken value, String objectDescription)
   at GitHub.Runner.Worker.ActionManifestManager.Load(IExecutionContext executionContext, String manifestFile)
Error: Fail to load dependabot/fetch-metadata/v1.3.2/action.yml

HI,

Thanks again for latest updates in v1.3.0 incorporating more alert metadata.
I tried enabling the new alert-lookup & compat-lookup options but I am getting a cryptic message Error: Resource not accessible by integration during the "Parsing Dependabot metadata" phase of the action. See the action run at https://github.com/SalimBensiali/le-blanc-jewellery/runs/5545641006?check_suite_focus=true

When not passing the additional options the action runs successfully, but obviously the additional metadata is not available in this case.

Is there anything else I would need to configure? I looked at the documentation and could not find anything else.

Thanks

First and foremost, I am not 100% confident this is the right place to report this in.
So, if not, feel free to move my request or me somewhere else.

Now, to the predicament at hand.
I maintain an open-source organization with several repositories utilizing Dependabot to ensure all our dependencies stay up to date.
As manual merging became too much of a burden to the team, I investigated how to employ auto-merge in our environment.

This investigation landed me on the Automating Dependabot with GitHub Actions page that describes how to achieve just that.
After going through the description step by step, I assumed everything was in place.
Thus I set an (in my case, dedicated) YAML for the auto-approval and auto-merge procedures and added branch protection rules for dependabot specific pull requests.

Although the GitHub configuration matches the branch protection rules with the dependabot PRs, some are merged regardless of whether the task succeeds.

After noticing this predicament, I went on a second investigation to figure out what I was missing.
This eventually led me to the README.md of this project, which also describes the auto-merge capabilities.

Furthermore, I noticed a slight discrepancy between this project's readme and the GitHub docs page.
The latter states the following on auto-merge:

If you want to allow maintainers to mark certain pull requests for auto-merge, you can use GitHub's auto-merge functionality.
This enables the pull request to be merged when any tests and approvals required by the branch protection rules are successfully met.
For more information, see "Automatically merging a pull request" and "Managing a branch protection rule."
You can instead use GitHub Actions and the GitHub CLI. Here is an example that auto merges all patch updates to my-dependency:

Whereas this project's readme states:

If you are using the auto-merge feature on your repository, you can set up an action that will enable Dependabot PRs to merge once CI and other branch protection rules are met. (Note that you must use a personal access token (PAT) when executing the merge instruction.)

The former seems to state that GitHub Action can be used instead of branch protection rules, whereas the latter describes the necessity of combining both.
Aside from being interested in the actual approach, I'm also wondering why my branch protection rules do not seem to block the auto-merge.

If anybody reading this can help me with that or guide me to somebody who does know, that would be very much appreciated.

Using this Action at v1.3.4 I'm getting various warnings that look like:

The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

This seems to be due to v1.3.4 using @actions/[email protected]. On the main branch of this repository, since #272, this has already been bumped to @actions/[email protected] which should resolve the warnings. As such, could a new version be releases so that the GitHub Action logs for this workflows using this action are clean again, thanks!

The above code seems to check whether or not the Actions actor is Dependabot and avoids calling the API if the actor isn't Dependabot. Can we consider checking the PR author instead of/in addition to the actor? The reason I ask for this is that there are times where I need to re-run the action and I don't want to have to get dependabot to recreate the PR via @dependabot recreate, since that takes more time.

The author is available in the PR event data and I'm able to access it in actions yml using github.event.pull_request.user.login

Happy to open a PR for this if desired

This would be really useful to have this value easily extracted and it would be possible to do many integrations with it.

If the PR is linked to a security alert, then it gets the severity of the security alert

Hi! My dependabot post workflow (It duplicates changes from pyproject.toml to mustache template pyproject.toml) ran dependabot/fetch-metadata action for getting newVersion and prevVersion values but they were empty (workflow run link).

I want dependabot PRs to automerge ONLY if the PR is to package.json. I have the following ci.yml.

jobs:
  npm-automerge:
    runs-on: ubuntu-latest
    if: github.actor == 'dependabot[bot]'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/[email protected]
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Merge without testing for dependabot npm PRs
        id: merge
        if: ${{ steps.metadata.outputs.package-ecosystem == 'npm' }}
        run: |
          echo "detected npm ecosystem"
          gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
      - name: Fail if not npm
        id: fail-not-npm
        if: ${{ steps.metadata.outputs.package-ecosystem != 'npm' }}
        run: |
          exit 1

Dependabot recently created a PR to upgrade a dependency in our package.json. The first step ran, the second step was skipped, and the third step ran and exited 1. I think this is a bug in the outputting of the metadata step. Either way, how can I get this to merge and pass?

In auto-merge permissions example, replace content by contents

thx

For some reason the fetch metadata is returning 404 response, not sure why. Could someone please take a look?

##[debug]Evaluating condition for step: 'Get Dependabot Metadata'
##[debug]Evaluating: (success() && (github.actor == 'dependabot[bot]'))
##[debug]Evaluating And:
##[debug]..Evaluating success:
##[debug]..=> true
##[debug]..Evaluating Equal:
##[debug]....Evaluating Index:
##[debug]......Evaluating github:
##[debug]......=> Object
##[debug]......Evaluating String:
##[debug]......=> 'actor'
##[debug]....=> 'dependabot[bot]'
##[debug]....Evaluating String:
##[debug]....=> 'dependabot[bot]'
##[debug]..=> true
##[debug]=> true
##[debug]Expanded: (true && ('dependabot[bot]' == 'dependabot[bot]'))
##[debug]Result: true
##[debug]Starting: Get Dependabot Metadata
##[debug]Loading inputs
##[debug]Evaluating: secrets.PAT_DEPENDABOT
##[debug]Evaluating Index:
##[debug]..Evaluating secrets:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'PAT_DEPENDABOT'
##[debug]=> '***'
##[debug]Result: '***'
##[debug]Loading env
Run dependabot/fetch-metadata@v1
  with:
    github-token: ***
    alert-lookup: true
    compat-lookup: true
    skip-commit-verification: false
    skip-verification: false
  env:
    REPO_URL: https://github.com/labxchange/labxchange/pull/376
##[debug]Verifying the job is for an authentic Dependabot Pull Request
Error: Api Error: (404) Not Found
##[debug]Node Action run completed with exit code 1
##[debug]Finishing: Get Dependabot Metadata

Hi,

I am getting the following error when upgrading from 1.3.1 to 1.3.2:

Download action repository 'dependabot/[email protected]' (SHA:90ed90dba204fdf8970c1f891b4349c96353f220)
Error: dependabot/fetch-metadata/v1.3.2/action.yml:
Error: dependabot/fetch-metadata/v1.3.2/action.yml: (Line: 18, Col: 113, Idx: 682) - (Line: 18, Col: 141, Idx: 710): While parsing a block mapping, did not find expected key.
Error: System.ArgumentException: Unexpected type '' encountered while reading 'action manifest root'. The type 'MappingToken' was expected.
   at GitHub.DistributedTask.ObjectTemplating.Tokens.TemplateTokenExtensions.AssertMapping(TemplateToken value, String objectDescription)
   at GitHub.Runner.Worker.ActionManifestManager.Load(IExecutionContext executionContext, String manifestFile)
Error: Fail to load dependabot/fetch-metadata/v1.3.2/action.yml

There seems to be a syntax error in the description field:

'true' vs `true`

Hello 👋 !

First of all, thanks for a great Github Actions plugin!

Second, I'd like to create a feature-request in regards to which events being listened too (or rather, skipped verified).

The 'problem' we're currently facing is that we're using Azure Pipeline to build/test/deploy/whatever, and also Github Actions to enable auto-merge of dependencies.

Right now, as our CI-platform is not on Github, we can't use any of the "run after" options, as there is no action defined to use as a trigger-point - since this is all handled on Azure DevOps.

However, in Github Actions, we can come by this issue by just defining the following on: clause, accompanied by a verification on which type of "suite" were executed, and what the "conclusion" for that check suite was:

on:
  check_suite:
    types:
      - completed
# ...
# ...(more stuff)...
# ...
jobs:
  dependabot-merge:
    name: 🤖 merge it
    runs-on: ubuntu-latest
    if: |
      github.event.check_suite.app.name == 'Azure Pipelines' && 
      github.event.check_suite.conclusion == 'success'
# ...
# ...(more stuff)...
# ...

This works as expected in other cases where we have an Github Action defined, however, not with the fetch-metadata-Action. The reason for it not working being located close to here: https://github.com/dependabot/fetch-metadata/blob/main/src/dependabot/verified_commits.ts#L18:

  if (!pr) {
    core.warning(
      "Event payload missing `pull_request` key. Make sure you're " +
        'triggering this action on the `pull_request` or `pull_request_target` events.'
    )
    return false
  }

We've added skipVerification: true, but, this won't have an effect as the event is being verified regardless. Would it be possible to add a new property for this (like: skipEventVerification: true or make this part of the skipVerification: true property? That would be great and it would solve our issue regarding this - or, if you have some other suggestion on how to achieve this, that would suffice too 🌮 😄 .

Thanks and hugs from,
vegard

Updating this action from v1.3.1 to v1.3.2 in a job causes the workflow to fail during the Set up job phase:

Download action repository 'dependabot/[email protected]' (SHA:90ed90dba204fdf8970c1f891b4349c96353f220)
Error: dependabot/fetch-metadata/v1.3.2/action.yml:
Error: dependabot/fetch-metadata/v1.3.2/action.yml: (Line: 18, Col: 113, Idx: 682) - (Line: 18, Col: 141, Idx: 710): While parsing a block mapping, did not find expected key.
Error: System.ArgumentException: Unexpected type '' encountered while reading 'action manifest root'. The type 'MappingToken' was expected.
   at GitHub.DistributedTask.ObjectTemplating.Tokens.TemplateTokenExtensions.AssertMapping(TemplateToken value, String objectDescription)
   at GitHub.Runner.Worker.ActionManifestManager.Load(IExecutionContext executionContext, String manifestFile)
Error: Fail to load dependabot/fetch-metadata/v1.3.2/action.yml

Reverting to v1.3.1 resolves this.

Looking at https://github.com/dependabot/fetch-metadata/blob/v1.3.2/action.yml#L18, it appears those backticks around a YAML identifier may be the culprit.

I'm using this action to enable auto-merge for Dependabot. Everything seemed to work fine, but the PR is not being merged. I'm not sure how to debug this and probably it doesn't have anything to do with the action but I don't know where else to report it 😬

It's been attempting to auto-merge for more than 24 hours now.

This is the PR nginxinc/nginx-asg-sync#108
and this the action https://github.com/nginxinc/nginx-asg-sync/blob/master/.github/workflows/dependabot-auto-merge.yml

Does anybody know how to fix this?

Thanks.

eg Bumps org/repo from v1.3.0 to v1.3.2. as a commit message does not populate the previous-version and new-version, so is also unable to calculate the proper update-type. This makes the output not very useful for determining whether to auto merge a dependabot PR only on minor version changes or less for example.

On this PR: aio-libs/aiohttp-demos#141

I'm getting Error: PR does not contain metadata, nothing to do.

What am I doing wrong?

Hi and thanks for this action.

I was wondering it the metadata had information about whether a PR raised by dependabot was due to a security alert/vulnerability.

Thanks.
Salim

Currently this Action in the Marketplace is not verified, which can be confusing and might has an security impact.
Usually all official GitHub Actions in the marketplace are "verified".

I noticed it when moving the "auto-merge" to the suggested procedure the suggested example in the GitHub Docs and it failed because my security setting for Actions did not allow unverified Actions (found in the repository settings).
While the workaround is straightforward by whitelisting this action, it would be great to have this Action verified in the Marketplace (probably requires some GitHub internal procedures).

Edit:
I think the entire organization dependabot needs to be verified as stated in these links:

• Publisher Verification
• How to become verified creator of a github action?

It would be great to re-use some of this logic in a probot bot. Would it be possible to publish this to npm?

Add support for the newVersion and prevVersion fields for updates with multiple dependencies.

Right now these fields are empty when there are multiple dependencies, so this affects both grouped updates and transitive dependency updates.

My team is trying to set up dependabot auto merge. We have auto approve working using the github token and granted PR write permissions but the same does not work for auto merge. Is there a way to get auto merge working without a PAT? Setting up a PAT for each repo in our Org isn't feasible.

Currently the README.md briefly mentions that alert-lookup needs a personal access token, but it doesn't specify what permissions are actually needed. It would be good to enhance that with a bit more detail such as:

This requires using a personal access token with the public_repo and security_events scopes. It is also necessary to give the user (whose personal access token is being used) access to view security alerts (see
Granting access to security alerts)

I'd initially assumed that I should just be able to use the built-in support for enhancing the default access token using the permissions: directive in GitHub Actions (as per the doc)

permissions:
  security-events: read

I assume this doesn't work because of the bit above about "granting access to security alerts", but it would be good to clarify that in the README and ideally raise the issue with GitHub Support, because it would be much cleaner if you could just do this rather than having to manage and rotate dedicated personal-access credentials for this

This action has an example for how to enable auto-approve:

In our repo and many repos, a previous approval is not invalidated by a rebase. And the default example causes dependabot to auto-approve every time it rebases that PR, this approval appears as an additional email for subscribed viewers. So, every rebase causes an email for the rebase and an email for the approval.

Proposed alternative command:

(gh pr status --json url -q '.needsReview.url?' | grep "$PR_URL" && gh pr review --approve "$PR_URL") || echo "PR already approved, skipping additional approvals to minimize emails/notification noise."

This alternative command would skip the approval if the PR in question isn't present in the needsReview section of the JSON output for gh pr status.

In addition to feedback on this docs update, if my command isn't optimal, I'd love for advice for a better command to use in its place. This requires relatively sophisticated shell-expressions, and I'd love to simplify this, and make it more robust.

Just spotted this error: https://github.com/dependabot/dependabot-core/runs/2728068808

(node:1705) UnhandledPromiseRejectionWarning: HttpError: API rate limit exceeded for installation ID 688580.
    at /home/runner/work/_actions/dependabot/fetch-metadata/v1.0.1/dist/index.js:3603:23
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
(node:1705) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:1705) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Looks like the action still checked out so we might want to rescue the octokit api request and bail out or print a more helpful error message.

First of all, thanks for the tool! It's really useful for filtering dependabot stuff

Now to my question:
As a context, I want to execute a specific step in my workflow only if the new version (from dependency) is exactly 1 patch ahead of previous-version (from dependency).
e.g.:

• v2.35.2 -> v2.35.3 ✅
• v2.35.0 -> v2.35.9 ❌
• v2.35.2 -> v2.36.0 ❌

Is there a simple way of getting this info or do I need to do string manipulation?

I'm asking because I don't know if steps.dependabot-metadata.outputs.update-type is util in this context.

Thanks!

(By the way, if I can suggest something, it would be nice to have the "question" type in the issues!)