Skip to content
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

Support subscribing to all features at once #374

Open
ocean90 opened this issue Feb 26, 2018 · 18 comments
Open

Support subscribing to all features at once #374

ocean90 opened this issue Feb 26, 2018 · 18 comments

Comments

@ocean90
Copy link

@ocean90 ocean90 commented Feb 26, 2018

As someone who wants to have all events pushed to a channel I currently have to do:

/github subscribe owner/repo
/github subscribe owner/repo comments
/github subscribe owner/repo commits:all
/github subscribe owner/repo branches
/github subscribe owner/repo comments

Having an alias like /github subscribe owner/repo all for this would be handy. Another idea would be to support a list of features like /github subscribe owner/repo comments commits:all ....

Related: #291

@kzap
Copy link

@kzap kzap commented Feb 28, 2018

@bleepers when will this be released or how do we know when there are new features?

@bkeepers
Copy link
Contributor

@bkeepers bkeepers commented Feb 28, 2018

@kzap This issue will get closed when the feature has been implemented.

@returnlytom
Copy link

@returnlytom returnlytom commented Mar 7, 2018

Ideally, a wildcard would work for both repos within an org, as well as features within a repo. For example:
/github subscribe owner/* *

This would subscribe to all repos in owner/ and enable all notifications.

@hcharley
Copy link

@hcharley hcharley commented May 3, 2018

For copy pasters looking for a quick command to do this:

/github subscribe owner/repo issues pulls deployments statuses public commits commits:all releases comments branches reviews
@stale
Copy link

@stale stale bot commented Jul 2, 2018

Is this still relevant? If so, just comment with any updates and we'll leave it open. Otherwise, if there is no further activity, it will be closed.

@stale stale bot added the wontfix label Jul 2, 2018
@dentarg
Copy link

@dentarg dentarg commented Jul 2, 2018

Absolutely

@stale stale bot removed the wontfix label Jul 2, 2018
@webdevbrian
Copy link

@webdevbrian webdevbrian commented Sep 27, 2018

Bookmarked @Charlex response

@setpixel
Copy link

@setpixel setpixel commented Jan 14, 2019

Would love to +1 this for a bump :D

@misthioseagle
Copy link

@misthioseagle misthioseagle commented Jan 27, 2019

issues pulls deployments statuses public commits commits:all releases comments branches reviews

Almost the 50th time I am coming here. I should bookmark this 😆

@dennissivia dennissivia self-assigned this Mar 29, 2019
@dennissivia
Copy link
Contributor

@dennissivia dennissivia commented Apr 12, 2019

I am currently working on this issue and I was wondering about the expected behaviour for the following case:

  1. A user subscribes to all
  2. A user unsubscribes from a specific topic like comments or so.

Should this be allowed or ignored or be an error? What do you think?

/cc @gimenete @wilhelmklopp

@wilhelmklopp
Copy link
Contributor

@wilhelmklopp wilhelmklopp commented Apr 12, 2019

@scepticulous that's a really good question.

Since this "subscribing to all" feature caters to the firehose/"I want all possibly activity" use case, I would definitely classify wanting to unsubscribe from specific features after you're subscribed to all as a secondary, less commonly needed use case (though I may be wrong about this).

And with that in mind I think I would just do whatever keeps the implementation simplest for now.

If we do go down the route of not allowing this (perfectly acceptable imho) it might be nice to show a message to the user that helps them understand how they would be able to accomplish the task (i.e. unsubscribe all, and then subscribe the individual types they care about)

@ntwb
Copy link

@ntwb ntwb commented Apr 17, 2019

@scepticulous Having just found this issue whilst thinking I'd like to be able to subscribe to *.*, if having done so, to then find out that notifications are far too noisy due to the volume of the comments on a repo then following up with /github unsubscribe owner/repo comments would be the logical step to remedy that scenario

@mariusnita
Copy link

@mariusnita mariusnita commented May 14, 2019

I would add that a wildcard subscribe like /github subscribe owner/* * as suggested by @returnlytom should subscribe to all current and future repos, not just the current ones.

@stale
Copy link

@stale stale bot commented Jul 11, 2020

Is this still relevant? If so, just comment with any updates and we'll leave it open. Otherwise, if there is no further activity, it will be closed.

@stale stale bot added the wontfix label Jul 11, 2020
@dentarg
Copy link

@dentarg dentarg commented Jul 11, 2020

Absolutely

@stale stale bot removed the wontfix label Jul 11, 2020
@redixhumayun
Copy link

@redixhumayun redixhumayun commented Nov 19, 2020

Is there any movement on this feature? This would honestly be great to have. I keep coming back to this thread to copy @Charlex 's command

@LTSCommerce
Copy link

@LTSCommerce LTSCommerce commented May 14, 2021

I found the copy/paste one liner above didn't work and had to trim this down to

/github subscribe owner/repo issues pulls commits commits:all releases comments branches reviews
@danb235
Copy link

@danb235 danb235 commented May 24, 2021

Updated copy/pasta since commits no longer uses all due to being a reserved keyword.

Note: Previously we you might have used commits:all to represent all branches. 'all' is no longer a reserved keyword. Going forward, you need to use '*' to represent all branches. If you have already configured with 'commits:all' previosly, dont worry, it will continue to work until you update the commits configuration.

/github subscribe owner/repo issues pulls commits commits:* releases comments branches reviews
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet