Renovate: platform.getPrList should return only Renovate's PRs

[rarkins]

[zharinov]

For Azure, although it's possible to filter by user ID, I can't obtain IProfileApi instance for the endpoint:
Could not find information for resource area 8ccfef3d-2b87-4e99-8ccb-66e343d2daa8 from server: https://dev.azure.com/szharinov/"

[viceice]

🤔 Missing some rights for your PAT?

[zharinov]

Don't think so, it's full-access

[rarkins]

For Azure can we instead filter after we get all results?

[viceice]

or maybe some of this apis?
https://github.com/renovatebot/renovate/blob/f3a3db4a4f9092a8327b929c2fdbab1ce4427e0a/lib/platform/azure/index.ts#L549-L593

[zharinov]

I think yes, I will just filter by branch for most of platforms where it's hard to obtain user id and filter by it

[viceice]

looks like gitlab and bitbucket-server are already doing filtering by api 🎉

[zharinov]

Probably, it's better to filter for bitbucket-server anyway: https://community.atlassian.com/t5/Bitbucket-questions/username-N-and-role-N-query-parameters-on-pull-request-REST-API/qaq-p/947557

[zharinov]

https://github.com/renovatebot/renovate/blob/master/lib/platform/azure/azure-helper.ts#L185 — this statement doesn't seem good to me, it results to pr.branchName === 'master'.

[viceice]

Probably, it's better to filter for bitbucket-server anyway: https://community.atlassian.com/t5/Bitbucket-questions/username-N-and-role-N-query-parameters-on-pull-request-REST-API/qaq-p/947557

Should already be the case

[viceice]

https://github.com/renovatebot/renovate/blob/master/lib/platform/azure/azure-helper.ts#L185 — this statement doesn't seem good to me, it results to pr.branchName === 'master'.

Is master by default, but can any of baseBranches or other

[rarkins]

@zharinov it doesn't seem right, branchName and targetBranch shouldn't be the same anyway

[zharinov]

Already fixed it and also made more testable, see #7211

[rarkins]

Our preference:

1. Submit our username or ID with the API query so that the platform efficiently only returns our own PRs
2. Filter based on our username/ID in platform, after getting results but before passing back to the application layer
3. Filter in the application layer based on branchPrefix

If (3) is necessary for any platform (Azure?) then I think it means we need to do (3) in workers/pr rather than platform.

[zharinov]

Haven't found filtering by author for Github v3 endpoint too, maybe v4 would help

[zharinov]

Though, we can easily filter by username ourselves

[zharinov]

For Bitbucket, some filtering options are available, need to check it out

[rarkins]

We don't typically care about the username at the application layer yet, only platform. So that's why I suggest to do the filtering there if possible. If not possible to compare the PR's author with our own identity then pass all PRs up to the application layer and we do another filter based on branchPrefix.

[zharinov]

https://github.com/microsoft/azure-devops-node-api/issues/411 just found my problem with azure api

[zharinov]

Can we use hidden comment in PR body, by which our PRs could be identified?

I understand, it's pretty dumb solution. But maybe, it's okay. I mean, once we have a trouble obtaining profile info, we've done with the entire repo.

[viceice]

there should already be some hidden content for renovate, but tha doesn't work on all platforms :-/

[viceice]

gittea has no direct api filter, but we can fetch our identity to filter on platform layer.

• https://try.gitea.io/api/swagger#/user/userGetCurrent

[viceice]

gitlab already filters by author api

[viceice]

Can we use hidden comment in PR body, by which our PRs could be identified?

I understand, it's pretty dumb solution. But maybe, it's okay. I mean, once we have a trouble obtaining profile info, we've done with the entire repo.

I think this can be problematic, if a user modifies the pr body, which should not (yet) happen.

[viceice]

Haven't found filtering by author for Github v3 endpoint too, maybe v4 would help

Nope, filter by author only via search api, which is very rate limited

https://github.community/t/filter-pull-requests-by-author/14494

[viceice]

github username is known after init platform, stored to config.renovateUsername so can be used to filter prs after fetch

[zharinov]

there should already be some hidden content for renovate, but tha doesn't work on all platforms :-/

Instead of hidden comment, something like str.endsWith('This PR has been generated by [Renovate Bot](https://togithub.com/renovatebot/renovate).') may work better.

I'm still unsure of the idea of detecting by body, but platform-dependent implementations for the pretty simple action also doesn't seem right to me.

[viceice]

🤔 but platform user is at least already known for github and gittea, so filtering should be pretty easy, bitbucket-server and gitlab already filter on author via api.

So we only need a solution for azure and bitbucket cloud

[zharinov]

That's also true. So I guess it won't be solved by one Pull Request. We need to:
(1) Search for application-level places where branchPrefix-based filtering can be applied anyway.
(2) Implement for what platform we can
(3) Wait for azure and then implement it too.

[rarkins]

Re: platform body. I want to do that soonish to make things better on some platforms, but not rely on it. So not applicable here.

[viceice]

• so lets fix github and gittea filter in (2) first
• then check bitbucket cloud for possibillities and fix that
• last wait for azure issue, then fix that too

[JamieMagee]

I'll see if I can contact the right person for the upstream Azure issue.

[zharinov]

For Bitbucket Cloud, the token should include ['account'] scope for this feature to work, otherwise we can't know our own uuid.

[zharinov]

Quick recap:

• [ ] Azure: https://github.com/microsoft/azure-devops-node-api/issues/411
• [x] Bitbucket
• [ ] Bitbucket Server: https://github.com/renovatebot/renovate/issues/7205#issuecomment-689559731
• [x] Gitea
• [x] Github
• [x] Gitlab

Until checked for all, we can't 100% rely on this filtering and have to check our branches in other places.

[rarkins]

Yes we should consider that filtering as an optimization (ideally reducing API answer size) but otherwise do filtering based on target branch