Skip to content
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

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

Open
davidrueckert opened this issue Feb 3, 2024 · 6 comments
Labels
bug Something isn't working

Comments

@davidrueckert
Copy link

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 davidrueckert added the bug Something isn't working label Feb 3, 2024
@fourpastmidnight
Copy link

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
Copy link

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!!!

@RobiNino
Copy link
Contributor

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 jfrog/jfrog-cli#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

@davidrueckert
Copy link
Author

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.

@fourpastmidnight
Copy link

fourpastmidnight commented Apr 17, 2024 via email

@RobiNino
Copy link
Contributor

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants