ci: make the whitespace checker more robust

[dscho]

I noticed that the checker failed to add a comment in one of my PRs. Turns out that the double-quote characters in the log output made it fail.

One thing we discussed earlier whether the log should be pasted as pre-formatted text or not, and we fell on the side of not pre-formatting it. However, in my tests, this does not look right, and it looks much better pre-formatted (even if we unfortunately lose the direct link to the commit).

Cc: Chris. Webster chris@webstech.net

[dscho]

/submit

[gitgitgadget]

Submitted as pull.778.git.1604418931303.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git pr-778/dscho/fix-whitespace-github-workflow-v1

To fetch this version to local tag pr-778/dscho/fix-whitespace-github-workflow-v1:

git fetch --no-tags https://github.com/gitgitgadget/git tag pr-778/dscho/fix-whitespace-github-workflow-v1

[webstech]

Thanks for correcting this. Interesting when escaping is done/not done.

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

>     One thing we discussed earlier whether the log should be pasted as
>     pre-formatted text or not, and we fell on the side of not pre-formatting
>     it. However, in my tests, this does not look right
>     [https://github.com/dscho/git/pull/18#issuecomment-721160985], and it 
>     looks much better pre-formatted
>     [https://github.com/dscho/git/pull/18#issuecomment-721167209] (even if
>     we unfortunately lose the direct link to the commit
>     [https://github.com/dscho/git/commit/68317764849af81b17c4b31906da20bdf2c52082]
>     ).

What is shown in the log are lines from the source files that were
checked, and we expect our source files are shown and edited in
monospace with tabwidth=8, I think it does make sense to force the
"pre-formatted" output.

Thanks.

[gitgitgadget]

This branch is now known as cw/ci-ghwf-check-ws-errors.

[gitgitgadget]

This patch series was integrated into seen via git@ba574db.

[dscho]

Thanks for correcting this. Interesting when escaping is done/not done.

Indeed.

In this instance, it is actually even more interesting to think of the time when things are interpolated. The ${{ ... }} constructs are interpreted when writing the script that is eventually executed, i.e. way before the script is actually run. The ${ ... } construct is interpolated while the script is run.

So by letting the ${{ ... }} interpolation happen in the env block, I avoid having node.js interpret the double quote characters, and by letting node.js interpolate ${ process.env.<something> }, I again avoid having node.js interpret the double quote characters because that interpolation is done inside the `...` quotes.

[gitgitgadget]

This patch series was integrated into seen via git@dc6020c.

[gitgitgadget]

This patch series was integrated into next via git@dc11218.

[gitgitgadget]

This patch series was integrated into seen via git@387a366.

[gitgitgadget]

This patch series was integrated into seen via git@c040efa.

[gitgitgadget]

This patch series was integrated into seen via git@15486b6.

[gitgitgadget]

This patch series was integrated into next via git@15486b6.

[gitgitgadget]

This patch series was integrated into master via git@15486b6.

[gitgitgadget]

Closed via 15486b6.