The Installation Repositories Event payload is missing removed repositories


#1

Steps to reproduce:

  1. Install integration with access to all repositories.
  2. Go to settings and switch to whitelisting a few repositories.

Bug:

The resulting IntegrationInstallationRepositoriesEvent webhook has the whitelisted repos correctly listed as repositories_added, but the repositories_removed field is empty, rather than containing a list of all repositories that I just lost access to.


#2

To add to this: When switching back from whitelisting repositories to “access all” there is no event fired at all.
The bug described in the OP is just annoying, but this one makes it impossible to keep track of installation repositories.

Btw, there is another problem kinda in the same region: There is a “public” event which lets me track visibility changes, but only in one direction. When a repository changes from public to private there is no way to track it and that makes enforcing plan/billing logic harder to implement/ impossible to do in real-time. Let me know if you want a separate ticket for that and where.


#3

Hey @boennemann,

Thanks for reporting these things IntegrationInstallationRepositoriesEvent observations. We’re looking into those, and we’ll report back.

There is a “public” event which lets me track visibility changes, but only in one direction. When a repository changes from public to private there is no way to track it and that makes enforcing plan/billing logic harder to implement/ impossible to do in real-time.

Good news. We added this functionality in April. You can check out the blog post or documentation for more details.


#4

@jmilas Thanks for your reply.

The option to receive RepositoryEvents wasn’t listed anywhere in the settings screen of my integration.
I didn’t request access to “Adminstration” at first, because it doesn’t list any events.

But after your reminder about RepositoryEvents I thought that you might just have forgotten to list them there. I created a new integration with access to administration, hoping that RepositoryEvents would now arrive, but they didn’t.

I tried to trigger “repository publicized”, but only “public” arrived. I tried to trigger “repository privatized” and nothing happened. I deleted a repository and again nothing happened, not even the IntegrationInstallationRepositoriesEvent for a removed repo.

So as of now I still have to report that it’s impossible to keep in sync with repos of an installation and their public/private state.

Thanks for looking into this.


#5

Thanks for your feedback @boennemann. RepositoryEvent isn’t currently available to Integrations. We’ll take a look at that and get back to you in the next couple of days.


#6

@boennemann, we’ve fixed up the installation repositories event payload bug you described - it should now include the repositories added or removed when switching to/from an install on “access all”, and the removed ones when switching to just whitelist a few. We’ve make a few changes to the payload - it will now just include a shortened version of the repository details, and will advise if the installation is on “selected” or “all”: full illustration in the docs.

Hope that helps.


#7

Hey @keavy,
thanks for the update. This is looking really good now :slight_smile:

Now all we’re missing is a way to stay up to date with public/private state of repos for billing purposes. We can still check that in a pull matter, but it would be cool if you’d push it to us, so we can always show up to date information w/o needing to sync first.

Thanks again,
Stephan


#8

Hi @boennemann

I just wanted to let you know we’ve added the ability to get Repository Events for integrations!

Please let me know if you have any questions, or if you run into any issues.

Thanks!


#9

Hey @tarebyte,

thanks for the great news.

You can’t change these after the integration has been created.

Are you thinking of a way to change the permissions of an Integration, which then prompts users to accept again?
We’ve started letting a few users onto the integration, and on top of getting users form oAuth to Integration, it would be an additional burden to migrate them to another Integration again. This is also giving use some naming conflicts, as the Greenkeeper integration is now taken.

Best,
Stephan


#10

For sure @boennemann. This is functionality that we plan to add. I don’t have a specific timeline at the moment, but we’ll be sure to keep you updated when we implement it.