Azure DevOps build failure (?)

[danielcweber]

I'm not sure if it's something that can be fixed within this repo, but it only happens when building with the latest IKVM (8.7.3). Azure DevOps build fails with

##[error]Unable to process command '##vso[task.logdetail id=20bb773a-a5c0-4823-bc6d-517ed9b383ae;parentid=;name=SLF4J [DEBUG];type=Build;starttime=2024-01-04T16:34:55.6346787Z;state=InProgress;]' successfully. Please reference documentation (http://go.microsoft.com/fwlink/?LinkId=817296)
##[error]Value cannot be null. (Parameter 'Type is required for this new timeline record.')
##[warning]SLF4J [DEBUG(,): Warning : ;linenumber=0;columnnumber=0;code=;]maven-site-plugin 4.0.0-M3 requires an update to commons-skin site.vm for new variable names.[\n]"
##[error]Unable to process command '##vso[task.logdetail id=20bb773a-a5c0-4823-bc6d-517ed9b383ae;parentid=;type=Build;result=Failed;finishtime=2024-01-04T16:34:55.6389298Z;progress=100;state=Completed;parentid=;name=;]' successfully. Please reference documentation (http://go.microsoft.com/fwlink/?LinkId=817296)
##[error]Value cannot be null. (Parameter 'Name is required for this new timeline record.')
##[error]Unable to process command '##vso[task.logdetail id=20bb773a-a5c0-4823-bc6d-517ed9b383ae;parentid=;name=SLF4J [DEBUG];type=Build;starttime=2024-01-04T16:34:55.6346787Z;state=InProgress;]' successfully. Please reference documentation (http://go.microsoft.com/fwlink/?LinkId=817296)
##[error]Value cannot be null. (Parameter 'Type is required for this new timeline record.')
##[warning]SLF4J [DEBUG(,): Warning : ;linenumber=0;columnnumber=0;code=;]maven-site-plugin 4.0.0-M3 requires an update to commons-skin site.vm for new variable names.[\n]"
##[error]Unable to process command '##vso[task.logdetail id=20bb773a-a5c0-4823-bc6d-517ed9b383ae;parentid=;type=Build;result=Failed;finishtime=2024-01-04T16:34:55.6389298Z;progress=100;state=Completed;parentid=;name=;]' successfully. Please reference documentation (http://go.microsoft.com/fwlink/?LinkId=817296)
##[error]Value cannot be null. (Parameter 'Name is required for this new timeline record.')
SLF4J [DEBUG] : << " warning : maven-site-plugin 4.0.0-M3 requires an update to commons-skin site.vm for new variable names.[\n]" [/home/vsts/work/1/s/Database/Fixtures/ExRam.Taxikomm24.Database.Fixtures.csproj]
##[warning]SLF4J [DEBUG(,): Warning : ;linenumber=0;columnnumber=0;code=;]Duplicate name in Manifest[\n]"
SLF4J [DEBUG] : << " warning : Duplicate name in Manifest[\n]" [/home/vsts/work/1/s/Database/Fixtures/ExRam.Taxikomm24.Database.Fixtures.csproj]
##[warning]SLF4J [DEBUG(,): Warning : ;linenumber=0;columnnumber=0;code=;]site-plugin 3.9.0 causes the following error:[\n]"
SLF4J [DEBUG] : << " warning : site-plugin 3.9.0 causes the following error:[\n]" [/home/vsts/work/1/s/Database/Fixtures/ExRam.Taxikomm24.Database.Fixtures.csproj]
##[warning]SLF4J [DEBUG(,): Warning : ;linenumber=0;columnnumber=0;code=;]Duplicate name in Manifest[\n]"
SLF4J [DEBUG] : << " warning : Duplicate name in Manifest[\n]" [/home/vsts/work/1/s/Database/Fixtures/ExRam.Taxikomm24.Database.Fixtures.csproj]
##[warning]SLF4J [DEBUG(,): Warning : ;linenumber=0;columnnumber=0;code=;]maven-site-plugin 4.0.0-M3 requires an update to commons-skin site.vm for new variable names.[\n]"
SLF4J [DEBUG] : << " warning : maven-site-plugin 4.0.0-M3 requires an update to commons-skin site.vm for new variable names.[\n]" [/home/vsts/work/1/s/Database/Fixtures/ExRam.Taxikomm24.Database.Fixtures.csproj]
##[warning]SLF4J [DEBUG(,): Warning : ;linenumber=0;columnnumber=0;code=;]Duplicate name in Manifest[\n]"
SLF4J [DEBUG] : << " warning : Duplicate name in Manifest[\n]" [/home/vsts/work/1/s/Database/Fixtures/ExRam.Taxikomm24.Database.Fixtures.csproj]
##[warning]SLF4J [DEBUG(,): Warning : ;linenumber=0;columnnumber=0;code=;]Duplicate name in Manifest[\r][\n]"
SLF4J [DEBUG] : << " warning : Duplicate name in Manifest[\r][\n]" [/home/vsts/work/1/s/Database/Fixtures/ExRam.Taxikomm24.Database.Fixtures.csproj]
##[warning]SLF4J [DEBUG(,): Warning : ;linenumber=0;columnnumber=0;code=;]Duplicate name in Manifest[\n]"
SLF4J [DEBUG] : << " warning : Duplicate name in Manifest[\n]" [/home/vsts/work/1/s/Database/Fixtures/ExRam.Taxikomm24.Database.Fixtures.csproj]
##[warning]SLF4J [DEBUG(,): Warning : ;linenumber=0;columnnumber=0;code=;]Duplicate name in Manifest[\r][\n]"
SLF4J [DEBUG] : << " warning : Duplicate name in Manifest[\r][\n]" [/home/vsts/work/1/s/Database/Fixtures/ExRam.Taxikomm24.Database.Fixtures.csproj]

"SLF4J" is a hint that this got something to do with IKVM. I assume there is nothing in IKVM that calls task.logdetail directly, but maybe there is a MSBuild task logging something with incomplete data.

Happy to investigate further.

[wasabii]

Are you talking about YOU building something with IKVM or IKVM itself building? I can't tell.

[danielcweber]

Sorry, yes, that is me building something on DevOps. The library being built has a reference to a nuget package that has MavenReferences.

[wasabii]

Yeah. This is weird. My guess is something is outputing something which ADO is detecting as an error line..... maybe just because it has the word error in it? I don't know....

I think Im going to need to have your help on it though. Don't have an ADO account around to try.

[danielcweber]

Happy to help. I updated my initial comment to include more output from the failing build.

[danielcweber]

A previous successful build mentions SLF4J a few times as well, but the failing build has a " [DEBUG]" suffix. From a successful build:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

[danielcweber]

I assume the square brackets are throwing DevOps off. I have no clue why the type of SLF4J changes, the referenced Maven package stayed the same between the successfull and failing builds.

[wasabii]

Hmm. So, the printout you showed from the previous Maven version is what I fixed in the newer version, by actually introducing a SLF4J StaticLoggerBinder, that routes SLF4J messages from Maven through into the MSBuild task, so the MSBuild task can actually log them to MSBuild.

My guess is some of those new messages contain characters that make ADO unhappy, maybe the brackets. Not sure what to do here..... do I need to like, remove any brackets from MSBuild logging messages for it to work on ADO? That's silly......

[wasabii]

I found this: https://github.com/microsoft/azure-pipelines-tasks/issues/2498

[wasabii]

Hmm. Okay. I think I found something. I'm calling Log.LogMessageFromText to proxy the SLF4J records into MSBuild. But it looks like Log.LogMessageFromText attempts to parse the string, and if it hits a specific "Canonical Format", transforms it into MSBuild warning/error output. So it's parsing the SLF4J text output, assuing it matches a pattern, and then marking it as error/warning output. Not sure why ADO has an issue with that though. Maybe ADO traps MSBuild errors/warnings specifically, and replaces it with task.logdetail, which breaks on the brackets. I can change this to LogMessage, instead of FromText, which isn't supposed to parse it. So it'll emit them as normal messages, instead of error/warnings. Maybe ADO will be fine with that. I'll try it. It's more correct anyways: I specifically know whether I want to log these as warnings/errors or not.

But if it's also parsing non-errors, and breaking on the brackets, it still won't work.

[wasabii]

@danielcweber Can you see if the latest IKVM.Maven.Sdk in the github package repo fixes it for you?

[danielcweber]

Will have a try

[wasabii]

Any status on this?

[danielcweber]

For the specific project that was failing in DevOps, I wasn't able to test this because we had to revert to a version that has neither this issue nor the one with libjvm failing to load. I will give 8.7.5 with the latest MavenSDK a try today and update the resp. issue. Thanks for hanging in there.

[wasabii]

Going to close this for inactivity. Reopen if still an issue.

[danielcweber]

I'm sorry I couldn't try to reproduce this because I'm currently on an older version where the libjvm-issue doesn't occur and that was already just fine to use with DevOps. I'm sure you caught the bug and it's fixed already. Thanks for the effort.