My gitlab projects trigger jenkins via webhook. Jenkins has a gitlab plugin which updates job status (penging, success or failed). Today I encountered a problem with gitlab jobs quota... Why is that? GitLab doc says they count minutes used by gitlab shared runner, but I am using external job. Any advises?
1 Answers
The GitLab plugin will trigger the use of a GitLab runner (possibly a shared runner, which does impact CICD minutes), if a job is triggered from GitLab.
Even when sending the build status back to GitLab, where it will be visible in the commit and/or merge request UI, it could involve a shared runner.
Check if that is the case by viewing your CI/CD minutes used by a personal namespace.
Note that See GitLab 15.1 (June 2022) adds:
View shared runner usage per project in a group
Using shared SaaS runners for public projects have the same CI/CD minutes limits as the corresponding tier the project is on. Users managing groups could see the total runner usage for the entire group, but could not see the usage for individual projects in one place. This made it hard to identify which projects within a group were using the most CI/CD minutes.
Now you can see the SaaS runner usage for the group by project, the same as you can in a personal namespace. It is now easier to find the projects that are using the most CI/CD minutes and, if necessary, make their pipelines more efficient.
See Documentation and Issue.
Plus, GitLab 15.2 (July 2022) adds:
Enforce per-plan webhook rate limits
Webhook rate limits will now be enforced for GitLab.com users to protect the performance and availability of the GitLab application. In return, the limit protects performance for all tenants.
Limits are applied per plan and per namespace and are based on the number of seats in your subscription, starting at 500 and up to 13,000 calls per minute per top-level namespace.
See Documentation and Issue.
Related