Thanks for the detailed explanation, that’s perfect and I understand exactly what you’re referring to.
Firstly, there’s a mistake with the comment command as you’ve cited it, as you’ve omitted the create part of the command. The CLI command would be:
acli jira workitem comment create --key "{key}" --body-file "tmp.json"
Also, there might be a mistake in the documentation for the Jira Comment Create command, as it says:
Options
--body-file string. Plain text file with text or Atlassian Document Format (ADF)
but you might have to specify the comment’s format as ADF using the --body option, not the --body-file option, the same as for the Jira Comment Update command. When I use the --help flag with jira workitem comment create command, the response matches the documentation and says the body file can be text OR ADF, so that’s a longshot that it’s a documentation mistake.
It’s strange that the Jira Comment Update command says:
Options
–body-file string. Plain text file containing comment body
so, it says nothing about being able to use an ADF formatted text file when updating a comment. It’s even stranger that, when updating an existing comment using ADF, you have to use a --body-adf option to ‘pre-warn’ the command what type of text string is being supplied, whereas that’s not required when creating a new comment.
You may have found a fault with the CLI’s ADF parser for the heading node, so have a go at formatting the tmp.json file as plain text using wiki markup and see if that works with the --body-file option. The plain text wiki markdown for a L1 heading would simply be:
#Test
Wiki markdown is often much easier to encode than ADF for simpler text entries.
Lastly, try declaring the wiki text and JSON encoded ADF version of the comment body directly into the jira workitem comment create command as a --body string and bypass using the intermediate text file. That might isolate the problem to being the mechanism that parses the file, not the actual ADF itself.