Add max length option to BranchNamer

[TomNaessens]

This PR adds a max length option to the BranchNamer and addresses #3107. Also relevant for the "... and may contain a maximum of 128 characters" part of #396.

This is a backwards compatible change and requires no configuration: when no option is passed, no truncating is performed on the branch name.

As this is my first contribution here, let me know if I missed some conventions, or if there are additional changes expected!

[jurre]

I'm worried that we'd end up with duplicate branch names in this scenario, as we'd end up truncating the bit that makes them unique (the version), and I think that could cause issues. Maybe we should truncate the dependency_name_part instead? From the linked issue it seems like this happens when a bunch of dependencies are updated in lockstep, so you end up with a long name part like: rails-and-draper-and-rails-controller-testing-and-rspec-rails-and-font-awesome-rails-and...

[nudded]

That's a valid concern.

Would you be okay with taking a hash of the full-length branch name and taking the first max_length characters from that if max_length is specified? (At some point we'd have to choose the lesser of 2 evils, we cannot deal with going over the limit, however then you do lose pretty branch names)

edit: your suggestion in the edit is probably better and more in spirit of what you want to achieve though 👌

[jurre]

Yeah a hash could also work, it's a tad safer I guess (if for some reason the combination of dependency names changes, it's still unique)

[TomNaessens]

Went for @nudded's suggestion with the safer hash. It's a bit smart in the sense that when part of the branch name can be kept, it is kept. E.g., for the branch "business-and-work-and-desks-and-tables-and-chairs-and-lunch", the results (including default prefixes) are:

80 chars: dependabot/bundler/business-and-work-and-desks-and-tables-and-chairs-and-lunch (fits within 80 chars)
70 chars: dependabot/bundler/business-and2a62321b0f24418298904dedd6dada473213321 (prefixes are saved, but is padded with hash to 70 chars)
50 chars: dependabotd2a62321b0f24418298904dedd6dada473213321 (still shortened including a bit of the prefixes)
40 chars: d2a62321b0f24418298904dedd6dada473213321 (just enough to store the full sha1 hash)
20 chars: d2a62321b0f244182989 (hash is shortened to make it fit within 20 chars)

It doesn't help that much for shorter max lengths, especially if prefixes are involved, but in the case where the max length is set to 150, I hope this will aid users when they can at least see the start of the branch name.

[jeffwidman]

Very clean solution @TomNaessens 👍

[jeffwidman]

Approving the CI runs for first-time contributor as the PR seems headed in a generally useful direction.

[TomNaessens]

Sorry, took a while to get the feedback processed. Let me know what you think of the changes!

[SimonSomlai]

@TomNaessens , thanks for opening this, we've also ran into a similar problem. Seems like there are just some linter issues left (most of which can be autocorrected);

@jeffwidman / @jurre, does this need more work, or do the changes look good? :)

[TomNaessens]

@TomNaessens , thanks for opening this, we've also ran into a similar problem. Seems like there are just some linter issues left (most of which can be autocorrected);

Thanks! Should be fixed now 🙇‍♂️

[jeffwidman]

Rebased, once CI passes I'll merge to main. We've been shifting to a "deploy-then-merge" strategy, but for community contributions that's not currently possible due to the way permissions on forks work, so will have to merge first. Probably won't get deployed to GitHub production til tomorrow or Friday, but that's fine in this case since the folks who need this are primarily using GitLab.