CODEWITHSUNDEEP
bashgoogle-cloud-platformgcloudgoogle-cloud-build
Simon Karman
Simon Karman

Reputation: 144

Alter 'status' request interval of CloudBuild submit

I'm trying to setup the CI/CD setup of a mono repository using Google Cloud Build. We have a single Cloud Build trigger that starts a build on a new commit, it does some general steps and then then starts a build for every (micro)service in the mono repository using gcloud build submit.

This however means that if 4 or 5 people are push code to the repository roughly at the same time we can have around 50-70 concurrent builds running in cloud build. Which in itself isn't an issue for us. The only issues is that when this happens the following errors will popup:

{
   “code”: 429,
   “message”: “Quota exceeded for quota metric ‘Build and Operation Get requests’ and limit ‘Build and Operation Get requests per minute’ of service ‘cloudbuild.googleapis.com’ for consumer ‘project_number:<PROJECT_NUMBER>’.“,
   “status”: “RESOURCE_EXHAUSTED”,
   “details”: [{
       “@type”: “type.googleapis.com/google.rpc.ErrorInfo”,
       “reason”: “RATE_LIMIT_EXCEEDED”,
       “domain”: “googleapis.com”,
       “metadata”: {
           “service”: “cloudbuild.googleapis.com”,
           “consumer”: “projects/<PROJECT_NUMBER>”,
           “quota_limit”: “GetRequestsPerMinutePerProject”,
           “quota_metric”: “cloudbuild.googleapis.com/get_requests”
       }
   }]
}

In other words: We are running into quota limits. The quota only allows us to only make 900 operational requests per minute.

quotas

We already tried switching to private pools in the hope that the above quota limit was only there for when you don't use private pools, but this unfortunately still makes us hit the quota.

Now, I am trying to find out if I can decrease the amount of these operational requests.

A possible solution might be related to how I am using gcloud build submit. When you run gcloud build submit, it starts a new build, waits for the build to finish, and shows the output of the build. To achieve this, I presume that gcloud is making requests every few seconds to find out what the status of the build is. I suspect that these 'status' requests are why my Cloud Build quota limit is reached. Which is why I'm trying to see how I can lower the amount of these requests per minute.

One option is to simple decrease the amount of builds running in parallel, which is unfortunately not an option in my situation. If I execute them sequentially it simply takes more time than acceptable in my situation.

Another option would be to increase the time in between such 'status' requests. However, on this page I did unfortunately not find a CLI flag to alter this.

Note: I did find the --async flag, however that does NOT help me, since I still want the process to wait until the build has succeeded. And I also did find the --supress-logs, which also does NOT help me, since these requests presumably don't interact with Cloud Build but with the GCS bucket where the logs are stored.

The only option left that I can think off, is that I can start my builds with the --async flag and then manually request whether the build has succeeded using a longer interval. However I do feel like that is a lot of manual work that, for which I need to write some bash scripts that need to be maintained. This preferably isn't a path I would like to take unless really necessary.

Does anyone know of another way of achieving this?

Upvotes: 1

Views: 235

Answers (1)

fabc
fabc

Reputation: 182

If 4 or 5 people are push code to the repository

This shouldn't happen. The reason it shouldn't happen is because you should use the "push" trigger on the main branch, not on a development branch.

  • What do I mean by this?

I mean that building should occur on the main branch, which would correspond to joined effort of those five users and a responsible party in charge of unifying their changes.
So, really, your users should be pushing to the development branch, and pushes to main should be reserved for things that need to be built.

  • How can we work around this if we're only allowed one branch or are required to have updates visible on one branch?

My recommendation would be to use the tag filter, specifically filter the pushes by tag, as mentioned in the documentation. That way only the pushes person in charge of merging the changes will be built (assuming that this person pushes to the tag you've set)

TL;DR

Don't create push triggers for Cloud Build on a branch multiple people are working on. Either create it with a tag filter or have seperate development and main branches (people work on dev, builds are only made from pushes to main)

Upvotes: 1

Related Questions