Update more CLI texts

[chgeo]

Make #1294 more generic and update more CLI texts.

• Use the <pre class="log"> approach instead of log code fence as it allows us to style the output more.
• Convert known terminal escape sequences to formats (mainly <em>, <i>, <strong>).
• Remove the versions numbers from the output as these would produce diffs for each new version, although the texts have not changed.
• Fix the workflow and produce a PR with a stable title. Parallel PRs seem unnecessary.
  • GH limitation: that PR cannot trigger new workflows. Workaround is to close and reopen the PR.
  • Example is chore: Update CLI texts #1303

This also gets rid of the custom renovate config to bump inner-md versions and the corresponding PRs.

[renejeglinsky]

I'd like to have a diff even if only the version number changed and not the text. Why not keep the versions up to date?

[daogrady]

I'd like to have a diff even if only the version number changed and not the text. Why not keep the versions up to date?

Was also my first impulse, but I see that the version number is no longer part of the output, so there wouldn't be any confusion for the user if they're looking at outdated versions. Plus if the version was still part of the output, this workflow would produce PRs for every patch version of our tools.
So I think this change makes sense, but if we do want to include the version number again, we should at least restrict it to major.minor and exclude .patch.

[daogrady]

Looks great, thanks for making this generalisation!

I played around with the script and it looks fine to me. My gripe with contributing workflows is that they're hard to test, so I'd say merge and see what happens¹? 🥲

Footnotes

1. unless the other reviewers have change-requests, ofc. ↩

[chgeo]

Was also my first impulse, but I see that the version number is no longer part of the output, so there wouldn't be any confusion for the user if they're looking at outdated versions.

Do you think the user is interested in the exact version? I doubt that and think they just assume they're looking at the latest text. Plus, the former output was a bit distracting like

> @sap/[email protected] cds --help

while this is what users know (and type):

> cds --help

Plus if the version was still part of the output, this workflow would produce PRs for every patch version of our tools.

This is what happens today through a custom renovate config, which turned out to produce quite a lot of rather dump 'just bump the version' PRs (example). This is what I want to reduce.

[chgeo]

My gripe with contributing workflows is that they're hard to test, so I'd say merge and see what happens? 🥲

I already tested the workflow. Turns out you can trigger workflows from non-main branches through the gh command line tool.

gh workflow run 'PR Latest cds-typer Output' --ref cli-out

What is strange though that I sometimes needed to use the old name PR Latest cds-typer Output while in some instances I could use the new name Update CLI Texts. Looks like a GH bug or so. See the latest run.

[daogrady]

Sorry, my comment was a bit vague. I initially had the same reaction as René, but after some consideration I came to the same conclusions as you did. So I think removing the version from the output is fine and even if we should reintroduce them, we should at least leave out the patch version.

[daogrady]

Turns out you can trigger workflows from non-main branches through the gh command line tool.

gh workflow run 'PR Latest cds-typer Output' --ref cli-out

Awesome! 😮

[chgeo]

I'd like to have a diff even if only the version number changed and not the text. Why not keep the versions up to date?

In the files where versions explicitly appear (like @sap/cds: 8.3.0), we do keep them up to date now, just not by single PRs from renovate but by only one for all texts.

The other thing @daogrady and I discussed was whether they should appear in command prompts like [email protected] --help, and here I'd say that's too confusing to read.

[chgeo]

Can we merge this?