At the moment, Dependabot checks once a day, which is fine for normal dep updates. However, we want browscap/browscap releases to almost immediately trigger an update check here, so we can consume the new release.
It seems this isn't possible at the moment: dependabot/dependabot-core#3080 - if there was an API call available, @FrankDeJonge suggested:
If that is available on the GitHub API then you can create an action for it by using that base action which is just a JS hook
The URL it would call is https://github.com/browscap/browscap-site/network/updates?update_config_id=<some-id> - however, the POST payload seems to be some kind of number-used once called authenticity_token, so my guess is this isn't easily hackable (I mean, it probably is, but it'll likely be brittle).
A workaround was suggested on Twitter by @bendavies :
so on tagging package A, trigger a workflow that updates repo B dependabot.yml in some way.
Whilst it may help, it seems a bit of a hack.
The alternatives at the moment:
Wait up to 24 hours for Dependabot to pick up the release and send the PR
Manually click the "Check for updates" button
It's worth noting that we'd have to introduce some kind of wait / polling of the Packagist API, since the release does NOT become immediately available (either when Dependabot checks, or occasionally I've seen Heroku not pick up the new release even!), so there will always be some lag whilst Packagist caches update, which we need to account for in any automated processes.
At the moment, Dependabot checks once a day, which is fine for normal dep updates. However, we want browscap/browscap releases to almost immediately trigger an update check here, so we can consume the new release.
It seems this isn't possible at the moment: dependabot/dependabot-core#3080 - if there was an API call available, @FrankDeJonge suggested:
The URL it would call is
https://github.com/browscap/browscap-site/network/updates?update_config_id=<some-id>- however, the POST payload seems to be some kind of number-used once calledauthenticity_token, so my guess is this isn't easily hackable (I mean, it probably is, but it'll likely be brittle).A workaround was suggested on Twitter by @bendavies :
Whilst it may help, it seems a bit of a hack.
The alternatives at the moment:
It's worth noting that we'd have to introduce some kind of wait / polling of the Packagist API, since the release does NOT become immediately available (either when Dependabot checks, or occasionally I've seen Heroku not pick up the new release even!), so there will always be some lag whilst Packagist caches update, which we need to account for in any automated processes.