feat: use comments if PR body is too long

[darrexx]

Changes

While creating PRs it is now checked if the maximum body length of the platform fits the whole PR body.

When the body is longer, some parts of the body are moved into comments.

For Onboarding PRs first the PR list is moved to the comments, and if the body is still too large, also the Detected Package Files are moved into comments.

For Update PRs first the changelog is moved to the comments, and if the body is still too large, also the Update Table is moved into comments.

If the body is still too long, it will be truncated, like it is now. Also if the platform limit for comment length is met, the comments are also truncated

Context

Our Team recently added renovate and we instantly noticed that the PR Body was missing information as the body limit on azure devops is 4000 characters.

Then we found this discussion with the idea to put some parts of the body into comments.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[CLAassistant]

All committers have signed the CLA.

[rarkins]

Previously smartTruncate() was exclusively a platform concept and used only in platform modules. With this PR it's now used in many places with lib/workers, which seems undesirable.

Did you try solving this in the platform only, to avoid this undesirable mixing of logic?

[darrexx]

I understand your point regarding smartTruncate().

After initally looking at the code, it seemed easier to fix this problem for all platforms. While smartTruncate() was called by massageMarkdown(), it was not possible to do this on the platform independent layer for all platforms, as the body would be truncated before the platform independent layer could check if the limit is read, so we moved it into there.

I think it is probably still better to adjust this for all platforms to ensure that no information is lost. In our tests we have had some PRs which were larger than 150000 characters, which would be larger than other length limits as well (e.g. bitbucket 50000)

As another Solution, we could maybe create a second function, like massageMarkdown(), which is called on the platform with the different contents of body & comments as parameters, to ensure that no text limit is reached.

[rarkins]

The key question is: does the worker layer need to have any awareness of how the PR body content is being split up? If not then this capability should be isolated to the platform layer.

[darrexx]

The alternative solution would be to have createPrBody() return an object instead of a string, which then needs to be concatenated according to the template in the platform code to build the body and possibly move some parts to comments, if the length limit is met. This way, the logic is moved to the platform.

I think both ways have some drawbacks:

As it is now:

• the worker layer is responsible for splitting of the body and moving parts to comments

Alternative solution:

• some responsibility for building the body is moved to the platform layer
• the platform needs to know if it is creating/updating an updating PR or an onboarding PR to split accordingly for the formats
• the platform needs to know the onboarding/updating templates to respect them when building the body