I would like to be able to raise a Bug in VSTS directly from a sentry issue. Ideally this would populate as much information as possible into the bug work item.
Yep, it is Visual Studio Team Services. If you go to https://www.visualstudio.com/ then click the āGet started for freeā button in the middle, you will be able to create a free account to have a look. You will need a Microsoft account to sign in with.
VSTS (based on the on-premises Team Foundation Server) provides different process templates per project in the account. The process templates define what type of work items are available for that project (like Bug, Task, Test Case etc). Agile is the most common one and there is also SCRUM and CMMI. Each process template has a bug concept although the fields may be different for each.
Weāll definitely explore it. Weāve been rebuilding the issue tracking (and notifications) extension support to make it easier to maintain as well as extend to other integrations:
One of the major remaining hurdles is to better handle systems which work with OAuth, but api key-based systems are extremely easy right now.
Is VSTS similar to Jira in that you can define custom columns? Iām digging through a bit to get a feel, and it seems mostly straight forward, but thats the big question. It looks like that likely our create issue flow would focus on identifying the story you want it attached to, and then passing in a basic title and description?
Weād be block on OAuth support to actually do this, but thatās something weāre going to implement soon.
Iāve had a quick glance over your vsts branch and have just a couple of comments (keep in mind I donāt know Python).
The title of the plugin seems to be āVisual Studioā (see plugin.py#L26). This seems misleading. Perhaps VSTS or TFS or VSTS/TFS would be more appropriate.
It looks like the config for the plugin only supports an account name (see plugin.py#L59) implying that this will only work for VSTS. This should really support on-premise TFS app tiers (exposed to the internet) by allowing the address of the TFS/VSTS webservices rather than just the account name. For example, a typical config of an on-premise TFS endpoint would be https://tfs.mycompany.com:8080/tfs.
Looks like the skeleton code is going to try to write to the history field (see client.py#L62). The history field is immutable. The closest to this would be the comment field although putting information in the description field would probably be more appropriate.
Thank you so much for working on this. It looks great
What about supporting plain http-accessible Git repositories? Our Git repository is hosted by on-premise TFS, but unless Iām overlooking something, shouldnāt this be something generic like:
I created a VSTS plugin for creating issues. The repo is at https://github.com/boylec/sentry-vsts. Iām still waiting on the sentry folks to get back to me about getting it up in production.
Currently it only lets one create work items from issues.
We will be adding TFS support in an upcoming version of Sentry, likely late in Q2/18. The reason we dont have bare repository support is because Sentry currently doesnāt not operate on VCS infrastructure (we dont ever fetch repositories). For our integrations we simply monitor commit metadata, and actually would prefer to avoid pulling down your source code for various security/privacy reasons.
Have there been any updates on the hosted TFS integration or is it basically forgotten about? I know that both VSTS and TFS are both basically being deprecated in favor of Azure Pipelines / Azure Repos, but we still self-host with TFS and I would love to be able to still get some sort of git integration with sentry without having to upgrade our whole source code stack.