PRs with special characters in the title can fail

[zimbatm]

When a PR has some special characters in the title like # (like when referencing another github issue in the title), the batch can fail with:

{:badarg,
 [{:binary, :match,
   [nil, {:bm, #Reference<0.3286459918.3038642177.151217>}],
   []},
  {String, :do_splitter, 3,
   [file: 'lib/string.ex', line: 414]},
  {Stream, :do_unfold, 4,
   [file: 'lib/stream.ex', line: 1354]},
  {Enum, :fetch_enumerable, 3,
   [file: 'lib/enum.ex', line: 758]},
  {Enum, :at, 3, [file: 'lib/enum.ex', line: 313]},
  {BorsNG.Worker.Batcher.Message,
   :"-generate_commit_message/2-fun-2-", 3,
   [file: 'lib/batcher/message.ex', line: 85]},
  {Enum, :"-reduce/3-lists^foldl/2-0-", 3,
   [file: 'lib/enum.ex', line: 1755]},
  {BorsNG.Worker.Batcher.Message, :generate_commit_message,
   2, [file: 'lib/batcher/message.ex', line: 84]}]}

I need to work a bit more on the reproduction of the bug.

It might be a utf-8 encoding issue?

[notriddle]

I think it's related to having a PR with no body text (which GitHub ends up sending as null, not an empty string) and having a defined cut-body-after declaration.

[grahamc]

For what its worth, sometimes (IIRC) GitHub will omit the field altogether on PRs with no body. I found this exact bug a few weeks ago with the Rust GitHub API client: softprops/hubcaps#107

[notriddle]

Now that I look at it, that actually makes no sense. It should be normalizing that nil away.

https://github.com/bors-ng/bors-ng/blob/master/apps/bors_github/lib/github/pr.ex#L74-L77