I don't want to subscribe a slack channel to all issues on arbitrary third party repositories, just to the particular issues on which my team/organization is involved (contributing to / impacted by), so the usual github integration command /github subscribe thirdparty/arbitraryrepo issues does not suffice as it would cause a ton of unwanted noise in the channel. (and the existing label filtering would not cut it)
(Update: there is an open feature request for that https://github.com/integrations/slack/issues/1280)
I neither want to forward my personal github subscriptions to the slack channel as there are lots of projects I am individually involved that have nothing to do with my team's work. (e.g. my direct mentions)
Also, subscription should stay despite I leaved the team/company.
A per-issue public RSS/Atom feed would cut it but it does not exist.
Am I missing something obvious?
The only workaround I can think of is adding a channel email integration, registering that address to an organization-shared github account and subscribe it to the individual issues we run into.
But this is quite cumbersome (must keep an alternate github logged-in session while browsing, channel readability could be abused to hijack company account, subscriptions can't be managed from the slack channel...) so any different idea would be very welcome.
As far as I know there is nothing that would suit your need completely at this moment, but have you considered labels?
#1 option You could use filtering based on label which seems to be the closest:
That would notify you about all issues, pulls, commits, releases, deployments that has a given label. Syntax example:
/github subscribe repo-owner/repo-name +label:"team-a"
Pros: a general filter based on a label name, e.g. team-a
Cons:
a single label filter only (AFAIK: multiple labels aren't supported but discussed: https://github.com/integrations/slack/issues/384)
this works only for a label given when issue/PR is created. Not during its existence ("change label" events are not triggered). Known bug (https://github.com/integrations/slack/issues/1594) and feature PR is open https://github.com/integrations/slack/issues/965
Note: a workaround to get info about label change in PR: to convert PR to a draft and back (https://github.com/integrations/slack/issues/965#issuecomment-1330884166)
#2 option Another thing that might be considered is that the account that is used within GitHub Slack app for connecting to Git server will be actually notified also about all its mentions, assignments & reviews! So if you don't use your personal account, you could get generated some related notifications to the whole team / other specific user etc.
EDIT:
Workaround steps to achieve partially what you want (but it can be in some conflict with your Slack / GitHub settings that I’m not aware of):
Use / create a shared account (or other special account) in GitHub
In Slack, use this special GitHub account for connecting Slack GitHub app to GitHub (this enables notifications by default for this account - mentions and assignments).
Then, when this GitHub account is assigned / mentioned, you’d automatically get notified (but again, then it would work not just for issues but hypothetically also in PRs etc.) to a dedicated channel where you'd have your GitHub integration set.
To auto-assign an issue, you'd have to use e.g. GitHub Actions.
Caveat: But as we discuss, there’s no simple way to achieve your goal completely. To at least get closer to something similar to what you describe and require, you’d need to accept some compromises and extra steps for workaround as it’s unfortunately not currently natively supported. 3rd hypothetical way is to create even more complex mechanisms of filtering & redirecting data which would be increase a level of complexity to just introduce but also maintain (unless you'd already have something similar existing in your infrastructure) and I wouldn't recommend it.
Related
I've been looking at organisation and project settings but I can't see a setting that would prevent users from creating work items in an Azure DevOps project.
I have a number of users who refuse to follow the guidelines we set out for our projects so I'd like to inconvenience them and the wider project team so that they find it better to follow the guidelines than not - at the moment we've got one-word user stories and/or tasks with estimates of 60-70 hours which isn't reflective of the way that we should be planning.
I'd still want them to be able to edit the stories or tasks and moving statuses, but that initial creation should be off-limits for them (for a time at least). Is there a way to do this??
The Azure DevOps Aggregator project allows you to write simple scripts that get triggered when a work item is created or updated. It uses a service hook to trigger when such an event occurs and abstracts most of the API specific stuff away, providing you with an instance of the work item to directly interact with.
You can't block the creation or update from, such a policy, Azure DevOps will inform the aggregator too late in the creation process to do so, but you can revert changes, close the work item etc. There are also a few utility functions to send email.
You need to install the aggregator somewhere, it can be hosted in Azure Functions and we provide a docker container you can spin up anywhere you want. Then link it to Azure DevOps using a PAT token with sufficient permissions and write your first policy.
A few sample rules can be found in the aggregator docs.
store.DeleteWorkItem(self);
should put the work item in the Recycle Bin in Azure DevOps. You can create a code snippet around it that checks the creator of the work item (self.CreatedBy.Id) against a list of known bad identities.
Be mindful that when Azure DevOps creates a new work item the Created and Updated event may fire in rapid succession (this is caused by the mechanism that sets the backlog order on work items), so you may need to find a way to detect what metadata tells you a work item should be deleted. I generally check for a low Revision number (like, < 5) and the last few revisions didn't change any field other than Backlog Priority.
I'd still want them to be able to edit the stories or tasks and moving statuses, but that initial creation should be off-limits for them (for a time at least). Is there a way to do this??
I am afraid there is no such out of setting to do this.
That because the current permission settings for the workitem have not yet been subdivided to apply to the current scenario.
There is a setting about this is that:
Project Settings->Team configuration->Area->Security:
Set this value to Deny, it will prevent users from creating new work items. But it also prevent users from modify the workitem.
For your request, you could add your request for this feature on our UserVoice site (https://developercommunity.visualstudio.com/content/idea/post.html?space=21 ), which is our main forum for product suggestions.
How can we search/filter GitHub issues for the ones you've previously marked as 'watching'?
I can't spot any way to do it via the GUI, but perhaps there's some search parameter?
I took a guess and tried watching:true and currentUser(), but neither seemed to work
You can see all your subscriptions at https://github.com/notifications/subscriptions. You can filter by reason and repository and sort by Most recently subscribed or Least recently subscribed.
Available subscription-reason filters
Any reason - Show all subscriptions
Assign - You were assigned to the Issue/PR.
Author - You created the thread.
Comment - You commented on the thread.
Manual - You subscribed to the thread (via an Issue or Pull Request).
Mention - You were specifically #mentioned in the content.
Review Requested - You were requested for review.
State Change - You changed the thread state (for example, closing an Issue or merging a Pull Request).
Team Mention - You were on a team that was mentioned.
You would not get a web-based search filter for "watched": the Advanced search does not include anything related to "watched/watching".
Even the GitHub API does not include anything regarding watching at the issue level.
There are only API calls for listing watchers at the repository level.
I have a Github repo which hasn't been updated for a long while (up until today).
I would like to notify users who cloned it in the past that the repo has been updated and that they better pull the changes.
Is there a way to do that?
You can use GitHub webhooks for this. You'll have to read the docs and add your own consumption logic for it.
If you rather not build your own consumption pipeline, consider using LightFlare (I'm the creator) that has out of the box support of consuming Webhooks events from many services (github included) and notifies you at your choice(s) of destinations (slack / email etc ...).
Research I've done before raising this question:
[github] single user pr - no relevant results
[github] single user pull request - no relevant results
[github] approve own pull request
github protected branch require pull request (Unanswered)
A potentially relevant question, but around a multiple user environment, so there were workarounds. I don't have a workaround.
'[github] approve own pr` - no relevant results.
Quite a few Google searches
So my problem is simple: I have a personal GitHub repository that I am using to manage my website code. I would like to prevent accidental check-ins to the master branch because I do not want the CI/CD pipeline that I'm building to trigger unless a feature is complete; I'm planning to use issue-linked feature branches to handle updates.
My problem is that I cannot seem to set this up without having someone else to approve the pull requests, which I don't have. So the question is: How, other than creating a secondary git account to handle PR's, can I protect a branch to prevent accidental check-ins from happening, without having someone else on my team to approve those pull requests?
I know that I can do this in Azure Repositories, however, I quite like the GitHub environment so I'd rather do this in GitHub.
I managed to work around this. At the time I made this request, I didn't have automated tests set up (Something I believe all projects should have for completeness). When I set up validation requirements to merge into Master, I could not directly check-in to Master because those checks had not been run.
I could still approve the PR myself, so that was allowable, however, I also had to ensure that all pipeline checks had completed before that PR could complete.
It's not a complete answer because if you are not running a CI/CD pipeline with test running you will not be able to take advantage - but it's easy enough to set something dummy up that will always pass to enable this solution. Until GitHub.com provides a self-approval allowance, it seems to be the best answer.
I'm always happy to hear alternatives though!
When using slack with GitHub, is there any option to send messages by checking labels. For example if in commit exists label "design", message will go to 'design' channel. Is there any ready implementation or we need to do something custom?
No, not yet (May 2018, a year after the OP's question)
This is still pending in integrations/slack issue 384
I'm a member of a Slack channel dedicated to a specific feature of a repo that covers a wide variety of features. Right now we have an internal Hubot to filter down to a specific label and then post messages to the channel.
It'd be cool if this official integration could replace our internal by allow subscribing to only issues/PRs that have a specific label instead of the entire repo.
So it is technically possible, but for now through the use of an external third-party bot.
There is PR for this feature, but has not yet been approved/merged (15 months after it was submitted)
https://github.com/integrations/slack/pull/797
Our team ended up creating a custom integration