Image description limit warning can be rendered in a code block

[jbrobst]

If an image's description is a code block at the limit cut-off point, then the length limit message is rendered in the code block. For example, this currently occurs with the nextcloud image:

[tianon]

The current implementation is here:

docs/push.pl

Lines 80 to 123 in 6e07544

	if ($lengthLimit > 0 && bytes::length($proposedText) > $lengthLimit) {
	# TODO https://github.com/docker/hub-beta-feedback/issues/238
	my $fullUrl = "$githubBase/$proposedFile";
	my $shortTags = "-\tSee [\"Supported tags and respective \`Dockerfile\` links\" at $fullUrl]($fullUrl#supported-tags-and-respective-dockerfile-links)\n\n";
	my $seeAlso = 'See also [docker/hub-feedback#238](https://github.com/docker/hub-feedback/issues/238) and [docker/roadmap#475](https://github.com/docker/roadmap/issues/475).';
	my $tagsNote = "**Note:** the description for this image is longer than the Hub length limit of $lengthLimit, so the \"Supported tags\" list has been trimmed to compensate. $seeAlso\n\n$shortTags";
	my $genericNote = "**Note:** the description for this image is longer than the Hub length limit of $lengthLimit, so has been trimmed. The full description can be found at [$fullUrl]($fullUrl). $seeAlso";
	my $startingNote = $genericNote . "\n\n";
	my $endingNote = "\n\n...\n\n" . $genericNote;
	my $trimmedText = $proposedText;
	# if our text is too long for the Hub length limit, let's first try removing the "Supported tags" list and add $tagsNote and see if that's enough to let us put the full image documentation
	$trimmedText =~ s%$supportedTagsRegex%$sponsoredLinks$1$tagsNote%ms;
	# (we scrape until the next "h1" or a line starting with a link which is likely a build status badge for an architecture-namespace)
	if (bytes::length($trimmedText) > $lengthLimit) {
	# ... if that doesn't do the trick, then do our older naïve description trimming (respecting utf8; see https://www.perlmonks.org/?node_id=1230659 and https://perldoc.perl.org/utf8)
	$trimmedText = $proposedText;
	utf8::encode($trimmedText);
	$trimmedText = $startingNote . substr $trimmedText, 0, ($lengthLimit - bytes::length($startingNote . $endingNote));
	# (deal with the potential of "bytes::substr" here cutting us in the middle of a unicode glyph, which is arguably a much worse problem than the markdown cutting described below 😬 again, see https://www.perlmonks.org/?node_id=1230659)
	$trimmedText =~ s/(?:
	[\xC0-\xDF]
	| [\xE0-\xEF] [\x80-\xBF]?
	| [\xF0-\xF7] [\x80-\xBF]{0,2}
	)\z//x;
	utf8::decode($trimmedText);
	# adding the "ending note" (https://github.com/docker/hub-feedback/issues/2220) is a bit more complicated as we have to deal with cutting off markdown ~cleanly so it renders correctly
	# TODO deal with "```foo" appropriately (so we don't drop our note in the middle of a code block) - the Hub's current markdown rendering (2022-04-07) does not auto-close a dangling block like this, so this isn't urgent
	if ($trimmedText =~ m/\n$/) {
	# if we already end with a newline, we should be fine to just trim newlines and add our ending note
	$trimmedText =~ s/\n+$//;
	}
	else {
	# otherwise, we need to get a little bit more creative and trim back to the last fully blank line (which we can reasonably assume is safe thanks to our markdownfmt)
	$trimmedText =~ s/\n\n(.\n?)*$//;
	}
	$trimmedText .= $endingNote;
	}
	$proposedText = $trimmedText;
	}

This TODO in particular has me laughing:

# TODO deal with "```foo" appropriately (so we don't drop our note in the middle of a code block) - the Hub's current markdown rendering (2022-04-07) does not auto-close a dangling block like this, so this isn't urgent 

It looks like they do now! 😄

Unfortunately, without a full "proper" markdown parser, I think this is going to be really hard to fix. 🤔

(The simpler answer would be to move more of the image description into upstream documentation, and link to it from here instead, so that it can shrink down under the length limit.)