Pipelines limitation for large PRs?

[Daniel]

Is there any limitations with Pipelines handling extremely large PRs?

We had an architectural change that modified ~8,000 files. A PR was created for these changes but the pipeline for PRs is not getting triggered (nothing runs). Our pipelines work fine for other PRs and commits, so I'm wondering if there is just a PR size limitation.

Anyone else run into something like this? And are there any workarounds?

[Theodora Boudale · Accepted solution]

Hi @Daniel,

I can see that you created a support ticket as well for this issue and one of our engineers answered it. I just wanted to share the reply here as well, for any other users who may come across your question with the same issue:

The reason why the pull request pipeline was not triggered is that the Pull Request has a very large message in the description field, which caused the webhooks service not to be able to process that message, preventing the build to be triggered.

The way that the pipeline's service gets notified that it needs to run a new build is through a webhook message. When there's any new commit in the repository or when a pull request is created/updated, a webhook request will be fired against the pipeline's service to start a new build. Since the webhook was not triggered in this case due to the size of the description field of the pull request, the pipeline's service was not notified and no build was triggered for that particular Pull Request.

This limitation is described in the Troubleshoot webhooks documentation, as per the following section:

Webhook payload is limited to 256 KB. Webhooks may silently fail to trigger if their payload is too large.

The workaround, if possible, would be to reduce the size of the description field of the Pull Request so the webhooks service can process the message. Testing in my own repository, I was able to get the build triggered when containing up to 2000 lines. However, we understand that this is not an accurate way of measuring the commit message/payload size.

Another option is to manually trigger the pipeline directly for a commit by going to the "Commits" page, opening the desired commit, and clicking on the "Run pipeline" option in the right side panel.

We also have a bug ticket on our public issue tracker related to this bug, which you can check at the following link :

• https://jira.atlassian.com/browse/BCLOUD-21021

I would suggest adding your vote there, so our engineering team can better understand the impact. Also, if you would like to keep informed about any progress on the fix of that particular bug, make sure to add yourself as a watcher as well so you will receive updates through your email.

Kind regards,
Theodora

[Aron Gombas _Midori_]

I haven't experienced it myself, what happens when you manually run the pipeline on the source branch of the PR?

(If that runs and the build is green, you may just want merge the PR this time and ignore the problem. I assume these mega-PRs are not made every day by your team.)

[Daniel]

Manually running a pipeline on the source branch works fine, so it seems like it's a problem associated with triggering a pipeline when a large PR is created. Maybe it's an undocumented limitation?...

Typically our PRs are in the tens of files. Our PRs trigger automated workflows for our release process, so I guess for this we can just merge and run the release manually.