Manually trigger an update for a specific dependency

[0xdevalias]

Currently dependabot runs on a schedule, and by 'some magic' decides which of the outdated dependencies it will open a PR to update next. We tend to keep this limit to a relatively small number of PR's (2), and often need to take some extra time to ensure dependency changes don't affect our codebase's stability (not nearly enough test coverage to trust that in an automated way yet)

While obviously we can update dependencies manually when needed (which is our current workaround), we've grown quite fond of the way dependabot captures all of the relevant changelog/etc information into the PR when it opens one.

It would be great if we were able to 'trigger' dependabot in some way to automatically bump a specific outdated dependency (probably with the ability to bypass the 'max open PRs' limit for these 'manual bumps'). The only 'difference' here would be getting triggered manually, it would still open the PR and do everything else in the same way as it currently does.

[thepwagner]

👋 thanks for the cool idea!

Today you can trigger Dependabot manually in the "Insights -> Dependency Graph -> Dependabot" section of your repository, but as noted this can't be targeted to a single dependency and is affected by the open PR limit.

[Mogost]

Seems that manually trigger does not work for package-ecosystem: "github-actions".

[websolutions-hamburg]

Manually trigger for package-ecosystem: "github-actions" works for me.

[chenrui333]

I am also interested about this feature as well. :)

[techieshark]

Curious if anyone has a workaround handy.

My current use case is to split code across two repos, and have a version change in repo A trigger a PR to update the lockfile in repo B (which relies on repo A). I could make a GitHub Action on repo A to run npm/composer in repo B, then automatically open a PR, but if I can avoid writing that code that'd be great (esp. if I use this pattern in various projects).

[thepwagner]

@techieshark you can push the updates to the .github/dependabot.yaml in order to trigger version updates immediately: https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates

Having repository A push the configuration file in repository B will update all dependencies, including repository A. It is wasteful, but the best workaround I know of atm.

[mwaddell]

Have you tried having a github action which runs when a dependabot-created PR is closed and issues a POST request to /{owner}/{repo}/network/updates?update_config_id={update_config_id} to force a new dependabot run?

[elgohr]

@mwaddell would need to do web-scraping to get the cookies (as the url is not an API-URL), right?

[mwaddell]

@mwaddell would need to do web-scraping to get the cookies (as the url is not an API-URL), right?

Yes, you're correct, so it's only useful for doing a manual trigger from a script (instead of having to go find the correct button through the UI), but it's not going to work if you're trying to script it from github actions.

If you want to trigger dependabot to rerun through github actions, the only ways I know of are pushing a change to the dependabot.yaml file (not a great solution) or adding comments to specific pull requests that dependabot has created.

[weronikadominiak]

Hi! I am also interested in being able to trigger dependabot re-run from Github Actions. Any chance of having that in future releases?

Thanks!

[SalimBensiali]

I would love to be able to do this too. A use case for this is when dependabot raises a security alert for a dependency, but is unable to raise a PR due to version conflicts. This usually happens when one or more dependencies are blocking a security update on a child dependency. When this occurs, what I am thinking to programatically be able to achieve in a workflow is:

• Find the dependencies metadata preventing the security update by parsing the dependabot PR error status (from the relevant GraphQL endpoint)
• For each of the said dependencies, instruct dependabot to raise a version update PR even if the of open pull request limit is exceeded. This is because it is already the case for security update PRs, which this particular type of version update falls under. I.e. it is a "regular" dependabot version update which unblocks a dependabot security update.

What would be even better is if this sort of behaviour was baked into dependabot by default.

[lestephane]

Until GitHub starts tracking dependents of private repositories, and use that information to trigger the smallest set of dependabot update checks, people will be forced to come up with DIY (and wasteful) solutions.

This needs to happen at least when the dependents belong to the same owner / org / enterprise.

[SalimBensiali]

The use case I mentioned above seems to be rendered completely obsolete by this recent update to Dependabot https://github.blog/changelog/2022-09-07-dependabot-unlocks-transitive-dependencies-for-npm-projects/ 🎉

Update: At time of writing, this seems to only be supported for npm. See https://github.com/orgs/community/discussions/32887#discussioncomment-3672220

[big-andy-coates]

Have you tried having a github action which runs when a dependabot-created PR is closed and issues a POST request to /{owner}/{repo}/network/updates?update_config_id={update_config_id} to force a new dependabot run?

The limiting factor here is obviously the non-deterministic update_config_id.

Would it be possible to make this deterministic?

Maybe accepting an id field in the dependabot yml file?

If it's a deterministic url, then it would be easy enough for community members to create GitHub actions, etc.

[jeffwidman]

Related:

• https://github.com/dependabot/dependabot-core/issues/2201

Although I do wonder if some of the need for this would disappear if we added support for realtime updates:

• https://github.com/dependabot/dependabot-core/issues/3488

[amacneil]

It would be very helpful if Github could offer a REST API endpoint to trigger a dependabot run, so that we don't need to use web scraping / stored cookies.

Looks like this issue is in the top 20 most 👍 on dependabot, and would be a quick win since there is already clearly a backend API for this.

[paulz]

is there a way to test if we configured dependabot correctly?

here is our YAML: https://github.com/paulz/self-hosted-runner-example/blob/main/.github/dependabot.yml

# Set update schedule for GitHub Actions

# https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot

version: 2
updates:
  - package-ecosystem: "github-actions" # See documentation for possible values
    directory: "/" # Location of package manifests
    schedule:
      # Check for updates to GitHub Actions every weekday
      interval: "weekly"

adding it to the repo did not do anything, do we just wait a week to see if works?

[jeffwidman]

@paulz please file a new issue for a question like that rather than posting on a somewhat unrelated thread, it creates noise for everyone else watching this issue for updates.

I moved your comment to #7125

[duaneking]

Dependabot is utterly broken.

It's not taking requests.

It's not giving errors.

There is no way to debug it.

We have no way to know what it's doing, or when it will respond.

At this point, it's become a distraction for me and my team.

We just want to be able to tell the robot what to do so we can have it do the right thing, instead of it acting stupid and blocking builds and wasting team members time and actively getting in the way.

This actively makes Github a pain to use, and creates problems for teams because now we're dependent on a third party entity in the form of this AI robot thing that we can't control, that actively hurts our productivity, and acts like the sort of employee we would normally never want to work with and would never hire because its so Irrationally unreliable that we don't want the bot on our team if we can't control it and make sure it acts safely.

To be clear, the current incarnation of dependabot is a bad actor, and we can't tell it apart from a supply chain attack at the moment, Because it's so unreliable.

Virtual or human, if somebody wants to be of assistance to the team, they need to be able to take direction and fix things, and thats an expectation that every person has for dependabot, And that expectation is being failed.

[mwaddell]

@duaneking Unfortunately, I have to agree with you. I started using Dependabot before GitHub bought it because it automated a lot of the busywork parts of managing software security and compliance. However, the project has been largely stagnant since then. The internal Dependabot team has been focused exclusively on scaling the existing code, and there has been little to no support for new features nor any coordinated governance of the open source community that cropped up around Dependabot to allow contributors to add these features ourselves. On top of that, major, critical portions of Dependabot are closed source, so there are major gaps in what the open source community can even help with had there been good community governance in place.

I had hoped that GitHub would model better open source project governance on this project, but (as evidenced by the hundreds of years-old issues that have remained untouched), that has not proven to be the case. In the meantime, I (and many others) have left for https://github.com/renovatebot/renovate which is vastly more configurable and already supports most of the feature requests that have been sitting open in this project for years. It does not support the same level of integration into GitHub as Dependabot, but it more than makes up for that with its level of configurability and true openness.

[htpaf]

@mwaddell I was looking at https://github.com/dependabot/cli as by the name alone it seemed that it could work to "trigger" dependabot just like GitHub clican trigger workflows.

It does not seem to be used for more than testing but could some small modification to thedependabot/clibe used as workaround perhaps, what do you think?

[LeftTwixWand]

Are there any updates on this topic?

[mwaddell]

@mwaddell I was looking at https://github.com/dependabot/cli as by the name alone it seemed that it could work to "trigger" dependabot just like GitHub clican trigger workflows.

It does not seem to be used for more than testing but could some small modification to thedependabot/clibe used as workaround perhaps, what do you think?

No, dependabot/cli is used for local testing and does not actually connect to the "real" dependabot instance so it cannot create PRs, it just runs a local test version and outputs what the PR would be if it could create it.