jfrog-azure-devops-extension icon indicating copy to clipboard operation
jfrog-azure-devops-extension copied to clipboard

JFrogDotnetCore@1 task with a restore command fails with a "create file" error if both arguments are passed, and collectbuildinfo is true.

Open davidrueckert opened this issue 1 year ago • 6 comments

Describe the bug

Using the jfrogDotnetCore@1 task with a restore command, a create file error is thrown if both a value is passed in the argument field and the collectbuildinfo field is set to true. If collectbuildinfo is set to false, the task successfully runs.

Current behavior

The task fails with this error. CreateFile /p:RestoreConfigFile=C:\a\4\s\unit-testing-using-dotnet-test\nugetv1.config: The filename, directory name, or volume label syntax is incorrect.

Reproduction steps

  • task: JFrogDotnetCore@1 displayName: dotnet restore test inputs: command: 'restore' arguments: '/p:RestoreConfigFile=$(Build.SourcesDirectory)\unit-testing-using-dotnet-test\nugetv1.config' artifactoryConnection: 'artifactory' targetResolveRepo: 'Nuget' collectBuildInfo: true buildName: '$(Build.DefinitionName)' buildNumber: '$(Build.BuildNumber)' includeEnvVars: true

Expected behavior

The task should successfully run using the passed arguments and publish the build information to Artifactory.

Azure DevOps extension name and version

JFrogDotnetCore@1

JFrog CLI version

2.52.9

Operating system type and version

Windows 2022 server

JFrog Artifactory version (if relevant)

No response

JFrog Xray version (if relevant)

No response

JFrog Distribution version (if relevant)

No response

davidrueckert avatar Feb 03 '24 00:02 davidrueckert

Actually, I'm finding if you use the argument field at all, you're bound to run into many any varied issues, even including not getting past the Initialize job step--which essentially means your pipeline doesn't run.

I've noticed:

  • No path separator normalization
  • Using certain path formats leads to invalid YAML that basically causes no steps to be seen in the build pipeline
  • When arguments are processed incorrectly, incorrect paths are generated, so your build fails at Initilizing Job when certain paths cannot be found.
  • When using "custom arguments" in the task, the command lines that are built to be used with dotnet contain some which have values that are unquoted, where those values have spaces, throwing off dotnet command-line argument processing.

In short, this task's command-line handling is simply broken and unusable.

I think I'm better off using a regular dotnet restore task and ensuring that my nuget.config file has a URL that points to the repository in question.

And lastly, this task doesn't even use V3 of the Nuget API, and so it doesn't play nice with some Nuget implementations, such as Baget (which doesn't implement the Nuget v2 API). Nuget.exe/dotnet doesnt' care and "figures it out".

This is just a poorly implemented task. I'd recommend others to refrain from using it.

fourpastmidnight avatar Mar 20 '24 16:03 fourpastmidnight

OK, an update:

The build failing on Initialize job was due to a bug in Azure DevOps Server when using an option to Clean all build directories. It works the first time, then all subsequent builds fail. I needed to start from a clean foundation to ensure package restore was working correctly.

Having said that, there is a problem with this task. The problem is, it ONLY uses the Nuget v2 API (even though there's a radio button selection for V2 and V3, with V3 being the default)--and our existing Nuget solution, Baget, does not implement the V2 Nuget API, so package restore FAILS using the Nuget configuration file generated by this task.

If Instead I provide my own configuration file, where I specify that the v3 API is to be used, everything works.

JFrog, please implement using the v3 Nuget API from this task when it's selected in the task!!!

fourpastmidnight avatar Mar 20 '24 16:03 fourpastmidnight

Hi @davidrueckert , I couldn't reproduce this issue. Does this happen with any other argument?

Note that the task creates a temporary nuget.config based on the Artifactory connection and resolution repository and uses it in the restore process. If you'd like to pass your own config please currently use the --configfile option instead of the /p:RestoreConfigFile one because JFrog CLI doesn't support the latter (I opened https://github.com/jfrog/jfrog-cli/issues/2522 for that matter).

Hi @fourpastmidnight , What JFrog CLI are you using? The task and JFrog CLI use the V3 protocol by default. The created configuration file should show it (for example<add key="JFrogCli" value="<path to resolution repository>" protocolVersion="3" />). If the issue persists with the latest JFrog CLI version (2.55.0 as of today), please open a separate issue with reproduction instructions and we'll try to reproduce it again.

Thanks

RobiNino avatar Apr 16 '24 14:04 RobiNino

Hi @RobiNino . It looks like the behavior in this issue has been corrected. It looks like two updates to this extension have been released since I opened this ticket over 2 months ago. This issue must have been corrected in one of those updates. As for using the --configfile jfrog cli argument, there is no field in the JFrogDotNetCore Task where I can add a Jfrog CLI argument. I suppose that I can't use this task if I need to use our own NuGet.config file.

davidrueckert avatar Apr 16 '24 19:04 davidrueckert

Thanks for the response. My particular issue is actually due to a bug in Artifactory that I'm working through with customer support. But thanks for the info on the correct parameter to use, in case I need it in the future for some reason.

Get Outlook for Androidhttps://aka.ms/AAb9ysg


From: David Rueckert @.> Sent: Tuesday, April 16, 2024 3:56:40 PM To: jfrog/jfrog-azure-devops-extension @.> Cc: Craig E. Shea @.>; Mention @.> Subject: Re: [jfrog/jfrog-azure-devops-extension] @.*** task with a restore command fails with a "create file" error if both arguments are passed, and collectbuildinfo is true. (Issue #476)

Hi @RobiNinohttps://github.com/RobiNino . It looks like the behavior in this issue has been corrected. It looks like two updates to this extension have been released since I opened this ticket over 2 months ago. This issue must have been corrected in one of those updates. As for using the --configfile jfrog cli argument, there is no field in the JFrogDotNetCore Task where I can add a Jfrog CLI argument. I suppose that I can't use this task if I need to use our own NuGet.config file.

— Reply to this email directly, view it on GitHubhttps://github.com/jfrog/jfrog-azure-devops-extension/issues/476#issuecomment-2059825158, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABUTP2LRWNVQA5VDWY4DSQ3Y5V67RAVCNFSM6AAAAABCXQIDLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJZHAZDKMJVHA. You are receiving this because you were mentioned.Message ID: @.***>

fourpastmidnight avatar Apr 17 '24 01:04 fourpastmidnight

@davidrueckert , Glad to hear the issue is gone. You may pass the --configfile argument just like you passed /p:RestoreConfigFile - through the arguments field. JFrog CLI modifies its behavior when certain .NET arguments are identified.

@fourpastmidnight , Thanks for the feedback!

RobiNino avatar Apr 17 '24 06:04 RobiNino