-
Notifications
You must be signed in to change notification settings - Fork 27k
Fix Azure Pipelines for t0000 #732
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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>
|
/submit |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): |
|
On the Git mailing list, Johannes Schindelin wrote (reply to this): |
|
This patch series was integrated into pu via 31b7fed. |
|
This branch is now known as |
|
This patch series was integrated into pu via d49787e. |
|
This patch series was integrated into pu via c56e86f. |
|
This patch series was integrated into pu via 33a3a7c. |
|
This patch series was integrated into pu via 009b1d1. |
|
This patch series was integrated into pu via 34a4796. |
|
This patch series was integrated into pu via 954c680. |
|
This patch series was integrated into pu via 2c7b568. |
|
This patch series was integrated into pu via d2b86f7. |
|
This patch series was integrated into pu via 87cd9d7. |
|
This patch series was integrated into pu via 7ea517b. |
|
This patch series was integrated into next via 0d6a975. |
|
This patch series was integrated into pu via eace8b9. |
|
This patch series was integrated into pu via 129edc2. |
|
This patch series was integrated into pu via d72fa76. |
|
This patch series was integrated into next via d72fa76. |
|
This patch series was integrated into master via d72fa76. |
|
Closed via d72fa76. |
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.
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.
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.
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.
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.