0

We were using an on premise Jenkins against an on premise GitBlit. This worked fine. Last week we migrated from GitBlit to Azure DevOps.

Our Jenkins Jobs now run with the PAT of a 'fake' Azure Account (not the 'Build Service Account' because that one can't be used by an on premise Jenkins). So for Azure DevOps this is a regular user. We found no other way to set this up. Using the PAT of an employee was not really a good option.

Problem now is that we are constantly hitting the Rate Limites with following error:

Request was blocked due to exceeding usage of resource 'ATCPU' in namespace 'VSID'. For more information on why your request was blocked, see the topic "Rate limits" on the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=823950).

enter image description here

After which the Jenkins Job fails.

This is a game stopper in our migration to Azure DevOps because there seems to be no way to adjust those Rate limits for a given user...

Do you have recommendations? Is there a way to increase those limits?

In the screenshot, what does the Count and TSTUs exactly mean? We have the idea that it's not about how many bytes are transferred but rather the number of Git Operations.

Our Jenkins Jobs mainly clone Git Repositories with the usage of local mirrors.

Improve this question

1 Answer 1

Reset to default
1

A Jenkins build has the same 200 TPU limit as an Azure DevOps build, in that they both get the standard user limit.

Azure builds treat each pipeline as a separate user, so if you have many pipelines using the same account it would mean sharing the limit across all builds.

200 TPU is a lot, so it's worth checking to see if you are doing something super inefficient in the build that may have gone unnoticed when things had no limit. For example, are you calling a git operation in a loop in there?

If you are only running one build, it just be doing something huge. These "TPU" values are very close to being equivalent to Azure database DTUs. That's a lot of activity... more than I'd expect one user to be able to generate unless your build churns git operations, or the repo has tons of large files, or some other "unusual" condition.

Improve this answer
3
  • 1
    Thx for the answer. We did migrate 160 Gitblit repositories to Azure Repos... And we have a couple of big repositories (+1Gb). So maybe that was the reason the 200 TPU was hit.... The day after the migration, we no longer saw that error.
    – Lieven Cardoen
    May 25 at 7:54
  • That's good news - did you do the migrations with the same user account? If so, that's likely to be the cause and your normal builds shouldn't hit the limit.
    – Fenton
    May 25 at 9:32
  • Yes. All migrations were done with the same account. Thx!
    – Lieven Cardoen
    May 25 at 11:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.