Not sure if it would work for this use-case, but have you considered git submodules? They seem to be designed to slightly modify projects your code depends on (e.g. to make repository_dispatch work).

Thanks for the idea! I experimented with git submodules in the past and the problem is that I have all my latex repositories checked out in my local texmf tree. The submodules will add additional copies of the files there, which will result in unpredictable behaviour of tex, which of the multiple copies of a file it will use. This makes any form of latex development very hard and I had to abandon submodules. Unless there is a way to use submodules without having them in the local repository, I don't think I can use them.

Unless there is a way to use submodules without having them in the local repository,

It sounds like one of the submodule configurations lets you do that:

• Deinitialized submodule: A gitlink, and a .gitmodules entry, but no submodule working directory. The submodule’s Git directory may be there as after deinitializing the Git directory is kept around. The directory which is supposed to be the working directory is empty instead.

  A submodule can be deinitialized by running git submodule deinit. Besides emptying the working directory, this command only modifies the superproject’s $GIT_DIR/config file, so the superproject’s history is not affected. This can be undone using git submodule init.

For what it's worth, this ending up pushing me down a path wherein I (who also wanted something like this) converted the external repo to a submodule. I have Dependabot configured to make PRs when it notices that that repo has updates.

Then, I can test the changed dependency, make sure my code works with it correctly, push to the PR branch, and merge when I'm happy.

Dependabot is still effectively a cron, though. If you were to rely on activity in your Probot, I think it would work out the same.

Michael‭ It would be great if you would summarise your approach in an answer!