Trigger update jobs via API

[jodastephen]

My desire is to have something I can add to a CI build script that tells dependabot a release has occurred in that repo. This would then cause dependabot to examine the repo, and raise PRs immediately on all the dependent projects in my organization. Effectively an API version of the "Bump now" button. Note that the trigger can't be a commit or tag on GitHub, because the release happens on CI after the commit/tag, so I don't think dependabot/feedback#301 applies.

When I first saw the API had /release_notifications/private, I thought that was the perfect solution and gave it a try, but it did nothing. I then noticed the reference to "live":

Notifes Dependabot of a private dependency release. In response, Dependabot will check all of the repos that belong to an organisation your access token has access to. If any use an outdated version of the dependency and have their update schedule set to live Dependabot will create update PRs for them.

Of course Maven does not support "live" today, so I assume that is why calling the API had no effect.

Moreover, its unclear why the API needs to know the version number, as dependabot can already parse that. All I want it to tell dependabot to bump the repo now via the API.

(The API docs are also unclear as to the meaning of "name". I'm assuming it is the repo name, as it wouldn't be much use to have to call the API once for every project in a Maven multi-module build).

I think I just want a "bump now" API endpoint specifying repo and package manager, but perhaps I'm missing something?

[greysteil]

Thanks for the feedback @jodastephen.

The live problem is frustrating here. My hunch is that Dependabot should just trigger updates even for update config not set to live if you hit the private releases API - would that make sense to you?

The version number is needed because in practice Dependabot doesn't just initiate a full update scan on your repos when it receives this webhook - it scans each of your repos to check whether any are using an outdated version (lower than the number entered) and initiates an update run for that specific dependency if it finds any.

On name, that's useful feedback. For Java, Dependabot is expecting the name to be in the format group_id:artifact_id, for example org.kohsuke:github-api.

[jodastephen]

Thanks, and yes, immediate updates seems to be what that API is for, so that sounds good.

Unfortunately, even with that change the API will be painful because every repo I have is maven multi-module, so I would have to make anywhere from 5 to 20 API endpoint hits to ensure the update happens (which isn't good for you either). So I would separately request a means to indicate via API that all dependencies hosted in a repo have been updated. (In my case, they are all updated to the same version, that will be a common case)

[jodastephen]

Was there any progress on this one? (ignoring the "live" setting when using the API, as a minimum) We're about to start creating the workaround (logging on to the web page to simulate pushing the button) but I don't want to do that if there is progress!

[artgos]

Hey,

We are using our internal nexus instance to hold released components - which are in turn used as dependencies in other (gradle - managed) projects. I might have for example dependency looking like: compile "my.int.org:my-custom-lib-impl:1.0.15"

I was trying to use private releases API to tell Dependabot that my.int.org:my-custom-lib-impl has a newer version, so I was sending POST request with the payload looking like that:

{
  "name": "my.int.org:my-custom-lib-impl",
  "version": "1.0.18",
  "package-manager": "gradle"
}

However - that information seems to be totally ignored - I was hitting 'Bump now' button many times on my repo using old my-custom-lib-impl, but no PRs were created, etc.

When can I use private releases API then? And is it possible at all to make Dependabot aware of our internal releases/ dependencies? [edit]: After some more rounds of experiments I see that API bump works only on dependencies fetched from repos accessible to Dependabot. I guess what I would like to have is an option to 'tell' dependabot what is the latest version of my internal dependency and make Dependabot react on that - even though that dependency is not resolvable from the outside.

[greysteil]

@artzag sounds like you figured this one out, but I'll update the API docs to make it as clear as possible that the releases API is just to trigger updates in Dependabot and that the new version details are not persisted in Dependabot anywhere (as each update run fetches the latest version details directly from the registry).

Changing that behaviour would be a big change to Dependabot - we'd basically need to make Dependabot's backend act as a registry for every language we wanted to support it in. That's not on our roadmap, and unlikely to make it on - we need Dependabot to be able to access your registry, rather than duplicate it.

[artgos]

Thanks for your answer @greysteil! Just to be more clear on that - triggering updates in Dependabot through API would be exactly what we need - if only Dependabot was not ignoring dependencies which are not accessible to it (stored in local repos). As far as I understood the code - it builds list of dependencies based on maven-metadata.xml. That would be cool if it considered also 'private-private' dependencies, so my update triggered through API would find its' match and create PR. There would be no need to store anything.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within seven days. Thank you for your contributions.

[jodastephen]

Sorry stalebot, but this issue isn't fixed, and is a big gap in the API.

[rebelagentm]

@jodastephen Thanks! We addeded the enhancement label to this issue, so it shouldn't get closed by Stalebot again.

[ajcann]

@greysteil Will ignoring the 'live' schedule in order to support 'docker', 'maven' and others be a large undertaking? I'm happy to throw up a PR if this component of Dependabot is exposed. Is this API endpoint going to continue to exist post absorption of dependabot preview into github?

[rebelagentm]

@ajcann Grey is no longer a developer.

@feelepxyz Thoughts on these questions?

[feelepxyz]

👋We've removed the live update schedule requirement from the release notification API: https://github.com/dependabot/api-docs#notify-dependabot-of-a-private-dependency-release 🎉

This fix doesn't cover all the requests in this issue (bumping local/un-resolved dependencies) but should hopefully fix some pain points.

Is this API endpoint going to continue to exist post absorption of dependabot preview into github?

It will most likely not exist in its current form. Hoping to replace it with something more integrated, possibly by giving more control over directly trigger update jobs through Actions somehow (very TBD!).

[ajcann]

@feelepxyz @rebelagentm Thanks for super fast addressing of this folks! Looks like it's working perfectly on our end with private docker registry updates.

Re: potential future deprecation of the endpoint. Any ideas on the best way to stay abreast of those types of changes in order to make requisite changes on our side when the time comes?

Really appreciate your work and help!

[feelepxyz]

Re: potential future deprecation of the endpoint. Any ideas on the best way to stay abreast of those types of changes in order to make requisite changes on our side when the time comes?

@ajcann we'll make quite a bit of noise when we start fully integrating Dependabot Preview with GitHub as it will probably include some product deprecations/migrations. You could also watch the API docs repo for any API related changes: https://github.com/dependabot/api-docs

[ajcann]

Thanks again!

[maciejmakowski]

is there by any chance an update to this that also works with "Github native" Dependabot?

I'm looking into the ability of automating the "check for updates" button click under /network/updates

[rohitpaulk]

+1, would be interested in this ^

[itsdax]

+1

[jeffwidman]

Related (but not a duplicate):

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

Also, I suspect if we implemented schedule: live, it'd remove the need for this:

• https://github.com/github/dependabot-updates/issues/121

[maciejmakowski]

The combination of the two would be even better - that you can bump dependencies via the API and you can choose which dependency or dependencies to bump

[broksonic21]

Seconding this -> I know it's an older ticket, but we'd love ability to trigger via API (or gh command) to kick off runs in all of our repos at once, so we can do a universal approve/disapprove cycle in one time bucket on our calendars. Scheduling helps, but it's not the same.