Skip to content

Conversation

@dscho
Copy link
Member

@dscho dscho commented Mar 19, 2020

When running t0000 in our Azure Pipeline, the "Publish Test Results" step complains about an invalid JUnit-style XML, and it is correct. Let's fix that.

When a test case is run in a subshell, we finalize the JUnit-style XML
when said subshell exits. But then we continue to write into that XML as
if nothing had happened.

This leads to Azure Pipelines' Publish Test Results task complaining:

	Failed to read /home/vsts/work/1/s/t/out/TEST-t0000-basic.xml.
	Error : Unexpected end tag. Line 110, position 5.

And indeed, the resulting XML is incorrect.

Let's "re-open" the XML in such a case, i.e. remove the previously added
closing tags.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho
Copy link
Member Author

dscho commented Mar 23, 2020

/submit

@gitgitgadget-git
Copy link

@gitgitgadget-git
Copy link

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

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

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> When a test case is run in a subshell, we finalize the JUnit-style XML
> when said subshell exits. But then we continue to write into that XML as
> if nothing had happened.
>
> This leads to Azure Pipelines' Publish Test Results task complaining:
>
> 	Failed to read /home/vsts/work/1/s/t/out/TEST-t0000-basic.xml.
> 	Error : Unexpected end tag. Line 110, position 5.
>
> And indeed, the resulting XML is incorrect.
>
> Let's "re-open" the XML in such a case, i.e. remove the previously added
> closing tags.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>     Fix Azure Pipelines for t0000
>     
>     When running t0000 in our Azure Pipeline, the "Publish Test Results"
>     step complains about an invalid JUnit-style XML, and it is correct.
>     Let's fix that.

Hmph, I have a vague recollection that I've seen this one, looked at
the patch and even understood the issue.  Did I then forget to apply
it back then?  If so, apologies for failing to do so before the
release.

Will queue.

Thanks.

> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-732%2Fdscho%2Fci-xml-error-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-732/dscho/ci-xml-error-v1
> Pull-Request: https://github.com/git/git/pull/732
>
>  t/test-lib.sh | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 0ea1e5a05ed..7f0c02c016b 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -1085,6 +1085,7 @@ finalize_junit_xml () {
>  		junit_time=$(test-tool date getnanos $junit_suite_start)
>  		sed -e "s/\(<testsuite.*\) time=\"[^\"]*\"/\1/" \
>  			-e "s/<testsuite [^>]*/& time=\"$junit_time\"/" \
> +			-e '/^ *<\/testsuite/d' \
>  			<"$junit_xml_path" >"$junit_xml_path.new"
>  		mv "$junit_xml_path.new" "$junit_xml_path"
>  
>
> base-commit: be8661a3286c67a5d4088f4226cbd7f8b76544b0

@gitgitgadget-git
Copy link

On the Git mailing list, Johannes Schindelin wrote (reply to this):

Hi Junio,

On Mon, 23 Mar 2020, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > When a test case is run in a subshell, we finalize the JUnit-style XML
> > when said subshell exits. But then we continue to write into that XML as
> > if nothing had happened.
> >
> > This leads to Azure Pipelines' Publish Test Results task complaining:
> >
> > 	Failed to read /home/vsts/work/1/s/t/out/TEST-t0000-basic.xml.
> > 	Error : Unexpected end tag. Line 110, position 5.
> >
> > And indeed, the resulting XML is incorrect.
> >
> > Let's "re-open" the XML in such a case, i.e. remove the previously added
> > closing tags.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >     Fix Azure Pipelines for t0000
> >
> >     When running t0000 in our Azure Pipeline, the "Publish Test Results"
> >     step complains about an invalid JUnit-style XML, and it is correct.
> >     Let's fix that.
>
> Hmph, I have a vague recollection that I've seen this one, looked at
> the patch and even understood the issue.  Did I then forget to apply
> it back then?  If so, apologies for failing to do so before the
> release.

I suspect that you think of 076ee3e8a2a6 (tests: fix --write-junit-xml
with subshells, 2020-02-12) which you indeed applied. This patch addresses
a different issue that I had not noticed until two weeks ago. I
purposefully held back on contributing it during the feature freeze phase.

> Will queue.

Thanks,
Dscho

>
> Thanks.
>
> > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-732%2Fdscho%2Fci-xml-error-v1
> > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-732/dscho/ci-xml-error-v1
> > Pull-Request: https://github.com/git/git/pull/732
> >
> >  t/test-lib.sh | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/t/test-lib.sh b/t/test-lib.sh
> > index 0ea1e5a05ed..7f0c02c016b 100644
> > --- a/t/test-lib.sh
> > +++ b/t/test-lib.sh
> > @@ -1085,6 +1085,7 @@ finalize_junit_xml () {
> >  		junit_time=$(test-tool date getnanos $junit_suite_start)
> >  		sed -e "s/\(<testsuite.*\) time=\"[^\"]*\"/\1/" \
> >  			-e "s/<testsuite [^>]*/& time=\"$junit_time\"/" \
> > +			-e '/^ *<\/testsuite/d' \
> >  			<"$junit_xml_path" >"$junit_xml_path.new"
> >  		mv "$junit_xml_path.new" "$junit_xml_path"
> >
> >
> > base-commit: be8661a3286c67a5d4088f4226cbd7f8b76544b0
>
>

@gitgitgadget-git
Copy link

This patch series was integrated into pu via 31b7fed.

@gitgitgadget-git gitgitgadget-git bot added the pu label Mar 23, 2020
@gitgitgadget-git
Copy link

This branch is now known as js/test-junit-finalization-fix.

@gitgitgadget-git
Copy link

This patch series was integrated into pu via d49787e.

@gitgitgadget-git
Copy link

This patch series was integrated into pu via c56e86f.

@gitgitgadget-git
Copy link

This patch series was integrated into pu via 33a3a7c.

@gitgitgadget-git
Copy link

This patch series was integrated into pu via 009b1d1.

@gitgitgadget-git
Copy link

This patch series was integrated into pu via 34a4796.

@gitgitgadget-git
Copy link

This patch series was integrated into pu via 954c680.

@gitgitgadget-git
Copy link

This patch series was integrated into pu via 2c7b568.

@gitgitgadget-git
Copy link

This patch series was integrated into pu via d2b86f7.

@gitgitgadget-git
Copy link

This patch series was integrated into pu via 87cd9d7.

@gitgitgadget-git
Copy link

This patch series was integrated into pu via 7ea517b.

@gitgitgadget-git
Copy link

This patch series was integrated into next via 0d6a975.

@gitgitgadget-git
Copy link

This patch series was integrated into pu via eace8b9.

@gitgitgadget-git
Copy link

This patch series was integrated into pu via 129edc2.

@gitgitgadget-git
Copy link

This patch series was integrated into pu via d72fa76.

@gitgitgadget-git
Copy link

This patch series was integrated into next via d72fa76.

@gitgitgadget-git
Copy link

This patch series was integrated into master via d72fa76.

@gitgitgadget-git
Copy link

Closed via d72fa76.

@dscho dscho deleted the ci-xml-error branch April 25, 2020 20:13
derrickstolee pushed a commit to derrickstolee/git that referenced this pull request May 23, 2025
Currently when the `core.gvfs` setting is set, several commands are
outright blocked from running. Some of these commands, namely `repack`
are actually OK to run in a Scalar clone, even if it uses the GVFS
protocol (for Azure DevOps).

Introduce a different blocking mechanism to only block commands when the
virtual filesystem is being used, rather than as a broad block on any
`core.gvfs` setting.
derrickstolee pushed a commit to derrickstolee/git that referenced this pull request Aug 5, 2025
Currently when the `core.gvfs` setting is set, several commands are
outright blocked from running. Some of these commands, namely `repack`
are actually OK to run in a Scalar clone, even if it uses the GVFS
protocol (for Azure DevOps).

Introduce a different blocking mechanism to only block commands when the
virtual filesystem is being used, rather than as a broad block on any
`core.gvfs` setting.
derrickstolee pushed a commit to derrickstolee/git that referenced this pull request Sep 2, 2025
Currently when the `core.gvfs` setting is set, several commands are
outright blocked from running. Some of these commands, namely `repack`
are actually OK to run in a Scalar clone, even if it uses the GVFS
protocol (for Azure DevOps).

Introduce a different blocking mechanism to only block commands when the
virtual filesystem is being used, rather than as a broad block on any
`core.gvfs` setting.
derrickstolee pushed a commit to derrickstolee/git that referenced this pull request Nov 7, 2025
Currently when the `core.gvfs` setting is set, several commands are
outright blocked from running. Some of these commands, namely `repack`
are actually OK to run in a Scalar clone, even if it uses the GVFS
protocol (for Azure DevOps).

Introduce a different blocking mechanism to only block commands when the
virtual filesystem is being used, rather than as a broad block on any
`core.gvfs` setting.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant