Support for cross-repository dependencies

[nesl247]

It would be awesome if this would work across repositories. That's actually the reason we looked into this bot.

[z0al]

Hey @nesl247 , thank you for opening this!

Yeah, working with dependencies across repositories sounds cool. Technically, at least for the automatic status update, it's limited to the repositories the bot has gained access once installed! Would you need to include dependencies from "external" repositories?

I will take a look to see what I can do ;)

[z0al]

@nesl247 it's not possible for me to support cross-repo deps for all repositories.

I may only support repositories allowed per installation e.g. if you installed the app on owner and allowed the app to access owner/repo-1 and owner/repo-2 it will only work for those allowed repos and not e.g. owner/repo-3 or webpack/webpack. In that case, would it still be useful or good enough for you?

[nesl247]

Yeah, that’s all I really need. Thanks so much.

[laughedelic]

@ahmed-taj could you clarify why it's not possible? It seems that the check here

https://github.com/ahmed-taj/dep/blob/da4aed8db829e4d3c98db282ff27c0d09eb7c40c/lib/check.js#L17

can access issues of any public repository. Or am I missing something?

[z0al]

Good question @laughedelic!

The app mainly listens to issue events(opened,closed), when an issue is closed we check if it's a dependecy of an open PR and update that PR's state accordingly!

The only - official - way to get issue events is through subscribing to GitHub webhooks. But you can't unless the owner of that repository installed the app and authorized access to it. In short, we won't get events when those public repository (who their owners haven't installed our little app - 99.9% of repos) issues updated.

And yes, we also run checks on a PR if new commits have been pushed to it, but that is just a double-check in case some webhooks failed to be delivered to the app due the current infrastructure limitations (free heroku plan).

I hope it's clear now :)

[laughedelic]

@ahmed-taj thanks for the explanation, I understand now where the limitation comes from: it's about event updates, not the state checks. But what if look at it from a different angle:

we also run checks on a PR if new commits have been pushed to it

So if you already check PR's status whenever it's updated, you could check any external issue-dependencies. Add a listener for any kind of PR update (comments, reviews, pushes, labels, etc.) and check dependencies states (regardless of whether they are external or not). What do you think about this approach?

[rsarky]

So if you already check PR's status whenever it's updated, you could check any external issue-dependencies. Add a listener for any kind of PR update (comments, reviews, pushes, labels, etc.) and check dependencies states (regardless of whether they are external or not). What do you think about this approach?

I dont this will work because an event will only be generated when a webhook is subscribed to.
And that will only happen when the app is installed in the repository.
So an external dependency where the app has not been installed is impossible to handle IMO

[laughedelic]

@rsarky you don't need to install the bot on other repos to check their issues (assuming repos are public). Here's a simple example:

• I have a repo laughedelic/foo where I installed this bot
• now I open an issue #42 in it and write a comment: Depends on rsarky/hello-world#1 (external dependency)

What does the bot do:

• listens on all issue (or pull-request) related events in my repo (in particular laughedelic/foo#42)
• I post a comment, push commits or do any other change to the issue
• the bot sees that #42 depends on rsarky/hello-world#1 and checks if it's open or closed
• changes the status of #42 accordingly

Notice that it doesn't need to react on events from rsarky/hello-world#1. It needs to change the status of a dependent issue, so it's enough if it reacts only on the events from it.

I agree that it's less efficient, but I'm just showing that it's possible to handle external dependencies.

[rsarky]

So what you are proposing is instead of subscribing to events from an external repo we passively check if the external dependencies are open or closed?

[laughedelic]

@rsarky correct.

[rsarky]

Hmmm.
I think it is a good idea although I have some questions.
How often will you poll the external repo for changes and when will you poll?