-
Notifications
You must be signed in to change notification settings - Fork 645
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide a webhook-style callback on nuget.org #1153
Comments
I like it, let's move this to NuGetApi to track for API v3 though. Copied to NuGet/NuGetApi#5 |
@anurse This is one old issue, however I don't see it anywhere though you mentioned it copied to NuGet/NuGetApi#5. Anyone know what happened to it? |
@Stephanvs , re-opening this issue, seems this proposal is not tracked. |
Push notification would be very valuable for me, and perhaps more consistent with the current state of development processes (particularly in the .Net Core world). Since packages are being updated more frequently with smaller changes I would like to be continuously updating my projects' references, building and testing them. This is particularly important in a security context where deploying patched libraries quickly (sic. automatically) is prudent. To achieve the above goal I currently have to poll Nuget for the latest package versions and compare that to the last response to identify changes. This is effective, but wasteful on both ends -- needless code executing in my systems to initiate the check, and code running in Nuget to respond the queries. Moreover, there is a trade-off between timeliness and cost that works against us. The ideal solution from my perspective would be to have nuget store a distinct (account, package, webhook) triplet and asynchronously POST to the hooks associated with a package when a new version is published (listed, release or pre-release). The payload could be as simple as the package name (requires more API calls by clients) but the more metadata the better since it obviates the need to hit the API in downstream event processing. Looking at the code (as a newbie), it seems this would not be a substantial modification to the package upload pipeline. A less ideal solution, but one I would support and be happy to process for downstream users, would be a full stream of updates ala Twitter's Firehose. |
I would like to use a web hook to update a github repo and trigger another project to be built based on the new dependency now on nuget. |
* Drop Microsoft.IdentityModel.Clients.ActiveDirectory (ADAL), pick up Microsoft.Identity.Client (MSAL) * Move to latest ServerCommon and NuGetGallery packages to pull in MSAL move * Update build tools to latest to drop ADAL reference in a tool Progress on NuGet/Engineering#4992
I could've used a webhook like that, a simple setting of a URL to which nuget.org will send notifications regarding activities in an account packages, like uploaded, published, and deleted (or unlisted). The arriving payload should include the package name, version, and relevant action. |
Related issue: #7392 |
if everyone who needs this upvotes the original message we'll have a better chance of having it. |
As a workaround one can create a mail client receiving the notifications and handling them, although this is error prone and requires larger code base (unless you find a way to integrate such special casing per email message with an existing email client, still an overkill in my opinion). |
Just like github (https://help.github.com/articles/post-receive-hooks), it would be awesome to have a similar mechanism built in nuget.org. This could open the door to interesting services on top of the gallery, such as smart indexing of packages content.
We talked about this idea during the OuterConf 2013, in particular how such a feature would enable building a smart intellisense service in VS that automatically installs packages from smart-tags in the text editor :).
This is something a user should be able to configure alongside his API key and other settings...
The text was updated successfully, but these errors were encountered: