Set defaults for the max length of PR branch names

[jeffwidman]

This PR added a param for setting max length of the branch name:

• Add max length option to BranchNamer #5338

However, we don't set a default value, which means many of our users never benefit from this. In fact, several months later we were investigating errors for hosted on on GitHub.com and realized we ourselves had forgotten to set this value!

So I vote we start setting a reasonable default for each platform within dependabot-core.

This is similar to what I suggested in:

• Add option to control PR description max length + set reasonable defaults for each platform #7487 (comment)

Implementing platform-defaults at first glance seems like a backwards-breaking change. However, given that branch names longer than these limits would already be erroring/failing to create, I don't think there's any backwards compatibility issue.

🤔 Do all users of this param set it to the max allowed by their platform? I can't think of a reason to pick a different value... So once we start setting that within dependabot-core, should we also remove the top-level configurable branch_name_max_length param? Might as well keep our public API surface small...

dependabot-core/common/lib/dependabot/pull_request_creator.rb

Line 51 in 6ba5296

:branch_name_prefix, :branch_name_max_length, :github_redirection_service,

@TomNaessens, you've got the most context here, what say you?

cc @SimonSomlai, @nudded as appears you also wanted this PR, do you simply set this value to the max of your platform?

[TomNaessens]

I can mostly only comment from a Gitlab (through dependabot-gitlab) point of view as I haven't used the max length setting outside of Gitlab.

To answer your question first:

Do all users of this param set it to the max allowed by their platform? I can't think of a reason to pick a different value...

No, users do set it lower than the max value for the platform. For example, on the Gitlab codebase I'm most active on, we have specific branch limits (53 chars) that are enforced by us (so not by Gitlab) as our staging infrastructure uses those branch names, and Kubernetes has specific branch name limits.
So, dropping the removing top-level configurable branch_name_max_length param would break the dependabot-gitlab part that allows us to set a specific max length for our use case. Relevant pieces of code in dependabot-gitlab are:

• Array of options containing the setting passed to the PullRequestCreator: https://gitlab.com/dependabot-gitlab/dependabot/-/blob/main/app/services/gitlab/merge_request/creator.rb#L11-16
• The array being passed to the PullRequestCreator: https://gitlab.com/dependabot-gitlab/dependabot/-/blob/main/app/services/gitlab/merge_request/creator.rb#L67

About the general proposal:

I vote we start setting a reasonable default for each platform within dependabot-core

That sounds reasonable to me! 😄 Like you already mentioned, it's a change that users would be able to benefit from "out of the box".

Only small thing I can think of is platforms having different limits for different versions of their platform. I can imagine that newer versions might enlarge the maximum value of fields, and when this is reflected in a dependabot-core default change, that might break it for self hosted instances of those platforms that have not been updated to that version (but run the latest version of dependabot-core). But that can then be solved again by explicitly limiting the max length in their configs, so I don't think that should be accounted for.