Renovate: Feature request: Add VSTS support

[davidyaha]

This project looks great! I love the pluggable env's you have going!

I would love it if you add support for VSTS.

VSTS is microsoft's code hosting and jira-like tool (used to be TFS I think).
It has good rest API as far as i've seen so I think it will be possible to create support for it as by implementing a plugin by creating a new API file like the current github and gitlab (https://github.com/singapore/renovate/tree/master/lib/api)

Attaching the API docs for anyone that would to have go with it:
https://www.visualstudio.com/en-us/docs/integrate/api/git/pull-requests/pull-requests

[rarkins]

Hi @davidyaha thanks for the suggestion. I wasn't actually aware of VSTS before. For anyone wanting to help push this along, I think that this historical help from @hbetts for GitLab support is a great example: https://github.com/singapore/renovate/issues/65#issuecomment-276266948

Essentially he went through the API and checked if the existing ones we had for GitHub can be replicated and while doing so added brief descriptions of the relevant endpoints. In this case for VSTS, I think that it would be best to:

(a) Base your comparison off the GitLab API, not GitHub (GitHub has some extraneous ones currently specific for the GitHub App)
(b) Focus only on the exposed functions in module.exports

[hutson]

The company I work for may also be interested in support for _Visual Studio Team Services_ (There's a small subset of engineering teams that use _VSTS_, formally _TFS_.).

A point that I really like about renovate is that it's architected from the start to support multiple SCM platforms, including, potentially, _VSTS_.

[jycouet]

Hi there,
I had a look yesterday and I think that it could be quite easy!

So in VSTS, you have a "Build" part where you can add "Task".
You have a set of defined task, but you can also develop one and publish it in the VSTS Marketplace. https://marketplace.visualstudio.com/search?target=VSTS&category=Build%20and%20release&sortBy=Downloads

In VSTS you can have different SCM, and Git is one possibility. I guess that we can start with this one since it's really close to GitHub/GiLab integration.

The main idea would be to just create a build with one task: "renovate" and it would do the job on the project

I'll have a look later :)

[jycouet]

From my previous post, this would be the ideal goal.
But anyway, the first topic is to add the vsts:git capability in renovate :)

I forked here: https://github.com/jycouet/renovate

I'll do something in the coming days.

[rarkins]

@jycouet great! Feel free to ping me for any questions

[jycouet]

As I said I started, and try to understand how everything works... it's ongoing 😄

The plan is:

• [x] a new platform: vsts
• [x] a nice lib doing like gh-got or gl-got (I found: vso-node-api)
• [ ] replace one by one methods in /lib/api/vsts.js (~20% done)
• [ ] create vsts tests
• [x] update the doc (get token for vsts, options for vsts, ...)

Any missing point?
Help is of course welcome 👍

[rarkins]

@jycouet that sounds great so far. The ideal first "working" step would be that you can run like this from source: VSTS_TOKEN=foo npm run start-babel some-user/some-repo -- --platform=vsts

i.e. it will switch to the vsts platform config and then renovate the some-user/some-repo repo.

[jycouet]

Hi @rarkins, the first step is working with my current fork

1. Run: $ renovate {repo} --token {token} --platform vsts --endpoint https://{instance}.visualstudio.com/DefaultCollection
2. It's creating a branch renovate/configure with a commit with one file renovate.json
3. It's creating a PR Configure Renovate with a nice content... update this and that lib

What could be the next step?

[rarkins]

@jycouet sounds great!

Although the Configure Renovate PR is essentially just a "dry run", you're already probably testing probably around 50% of the APIs because it still creates a branch, commits files and raises that PR.

I guess next step is to merge that PR and then test how it goes creating the real upgrade PRs.

BTW one important piece of functionality is what we are referring to in Renovate as "rebasing" (although it's not technically a git rebase that we're doing). i.e. if a Renovate branch becomes problematically outdated or conflicted, we manage to recreate the branch in GitHub and GitLab without causing a new PR to be created. Have you found whether that is possible in VSTS?

In GitHub, we do it with low level GitHub git operations via API. i.e. creating the git blobs and tree manually and then moving the branch ref to this new tree. In GitLab it's simpler, because they don't close a PR if the branch it points to disappears - so we can just delete the existing branch and create it again with new content and it's linked back together again by GitLab as if nothing happened.

[jycouet]

Hello @rarkins,
I spent a bit of time on the topic in the last days, and I have some good news:

• The first run creates the PR Configure Renovate well 👍
• After having the renovate.json in my repo, renovate creates well PRs with update dependencies (like: Update dependency @types/node to v8, Renovate accounts packages, ...

Few "surprise":

• PR body can have only 4000 chars (I cut at 4000 now)
• PR body doesn't support html (ul li for example!) => can we have only markdown there?

I will create a PR now so that you can give me feedbacks and see how to continue... 👍

[rarkins]

PR body can have only 4000 chars (I cut at 4000 now)

I guess some limit is to be expected. I already have some code for GitHub to try to gracefully do this by removing updates/commits from the PR until the generated PR body is short enough. But for GH I'm calculating HTML size, not Markdown. Here it is: https://github.com/singapore/renovate/blob/master/lib/workers/pr/index.js#L130-L145

PR body doesn't support html (ul li for example!) => can we have only markdown there?

That's a pity. Does it forbid HTML altogether or just fails to support HTML inside markdown? Because I had switched to submitting pre-compiled HTML, check out the link above. Can you clarify if you're using this updated code/commit or perhaps branched earlier?

[jycouet]

Unfortunately, VSTS doesn't render html in the PR body. It's only in the "Wiki section" that you can have html tags (source).
So it look like this:

Any reason why you generate html and not use only markdown?

---

Shoud I invite you on a vsts repo for you to see it in action?
Could you create a "todo" list of what needs to be done to continue?

[rarkins]

Any reason why you generate html and not use only markdown?

Because "GitHub flavoured markdown" and "GitLab flavoured markdown" behaved differently, I switched to precompiling the HTML - using GitHub's flavour - to get consistency across both and reduce the chances something in future looked bad in GitLab. It is a bit challenging to switch back to pure markdown.

Shoud I invite you on a vsts repo for you to see it in action?

Yes thanks. Do I need to create an account first to be invited or can you invite by email address?

Could you create a "todo" list of what needs to be done to continue?

Let's do that in the PR. First I'd start with.. can you make sure you have merged from the latest master commit so that it's up-to-date?

[jycouet]

It is a bit challenging to switch back to pure markdown

Yes, I understand. And it's most probably not the first focus ^^

---

My PR is up-to-date :)

[jycouet]

For info, I built an extension for VSTS: Renovate Me