feat(datasource/azure-pipelines-tasks): Azure DevOps API based datasource

[bdovaz]

Changes

Initially as I do not have much experience of the Renovate API, I tried (looking at other code examples in this repository) that only changes the behavior for the case that you are running it from platform: azure because this way there is no need to create any new variable and it can use the values of RENOVATE_PLATFORM, RENOVATE_ENDPOINT and RENOVATE_TOKEN.

This PR does not solve the case that platform is a value different to azure (in that case it makes fallback to what it was already doing) because for that case I suppose that new variables will be needed and I consider that this can go in another future PR because it requires more analysis.

Context

The need comes from the fact that we currently take as a source of data the static files that are generated from this repository: https://github.com/renovatebot/azure-devops-marketplace

The problem is that task updates are not propagated at the same speed to all Azure Devops organizations so there are times when renovate mistakenly suggests updating to versions of tasks that do not exist in the organization and if you do not know why it happens it is very confusing.

There is an open discussion: #24820

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[CLAassistant]

All committers have signed the CLA.

[rarkins]

Are you sure that this can replace the existing functionality in a backwards-compatible way?

How efficient is this approach? e.g. how many API calls and how many MB should it require each run?

Any caching possible?

[rarkins]

It's not certain that RENOVATE_TOKEN is defined. Instead, use hostRules to get the token

[bdovaz]

I have used the GlobalConfig and hostRules based on other data sources but I don't know if I have done it right.

I don't see any API documentation, I've only seen the pages you recommend here: https://github.com/renovatebot/renovate/blob/main/.github/contributing.md#code

[bdovaz]

Are you sure that this can replace the existing functionality in a backwards-compatible way?

How efficient is this approach? e.g. how many API calls and how many MB should it require each run?

Any caching possible?

Doesn't the caching already do it with the code that was there?

https://github.com/bdovaz/renovate/blob/620fa90803e995e404e29c478b1cfcd32ad028f8/lib/modules/datasource/azure-pipelines-tasks/index.ts#L81

And the backwards-compatible thing is for when these conditions are not met that it at least does what it did before:

https://github.com/bdovaz/renovate/blob/620fa90803e995e404e29c478b1cfcd32ad028f8/lib/modules/datasource/azure-pipelines-tasks/index.ts#L36

I've also added more tests to compare function so we have 100% code coverage.

[rarkins]

So it caches once per 24 hours, if the user has persistent datasource caching? (note: most people running Renovate in pipelines do not have such persistence)

I don't understand your answer to my backwards-compatibility question. Is it replacing existing logic, or adding to it? If it's replacing it, is it fully backwards compatible?

How many API calls and how many MB should it require?