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

JFrog Nuget task does not show the correct URL #489

Open
fourpastmidnight opened this issue Mar 27, 2024 · 2 comments
Open

JFrog Nuget task does not show the correct URL #489

fourpastmidnight opened this issue Mar 27, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@fourpastmidnight
Copy link

fourpastmidnight commented Mar 27, 2024

Describe the bug

I had an issue where packages were failing to be restored during my build. I'm using a stage Azure DevOps environment with outdated production data. Apparently, the packages in question were not cached internally in our existing Baget nuget server instances, and they are no longer on Nuget.org.

Long story short, I didn't realize this and was trying to resolve the packages manually via nuget.exe. Using the URL provided in the build log output from the JFrog Nuget task, the URL has the following format: https://test.myartifactory.mydomain.com:8082/artifactory/api/nuget/v3/my-build-dependencies-virtual—notice that in the URL, it does not end with /index.json. So, when searching for the package using nuget.exe with the URL shown above, it does not work. I get a HTTP 404 response.

Current behavior

Currently, the JFrog Nuget task does not display the full URL being used when querying for packages from Artifactory, unlike the JFrog .NET Core task, with does display the full and correct URL.

JFrog Nuget Task Log Output:

Feeds used:
    https://test.artifacts.<REDACTED>.com:8082/artifactory/api/nuget/v3/<REDACTED>-build-nuget-virtual
17:53:48 [Error] exit status 1
##[error]Error: Command failed: D:\Agent01\_work\_tool\_jf\current\jf.exe nuget restore -NoCache -PackagesDirectory "D:\\Agent01\\_work\\3\\s\\packages\\" -Verbosity "Normal" --build-name="<REDACTED> - Test Artifactory Integration" --build-number="<REDACTED>"
Executing JFrog CLI Command:
D:\Agent01\_work\_tool\_jf\current\jf.exe c remove "<REDACTED> - Test Artifactory Integration_<REDACTED>_nuget_resolver_1711490025160" --quiet
Finishing: Restore .NET Framework NuGet Package Dependencies (JFrog)

Here's the similar output at the end of the build log for the (correctly logged) JFrog .NET Core task:

         Feeds used:
             https://test.artifacts.<REDACTED>.com:8082/artifactory/api/nuget/v3/<REDACTED>-build-nuget-virtual/index.json
     1>Done Building Project "D:\Agent01\_work\3\s\<REDACTED>.sln" (Restore target(s)).

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:08.94
17:53:40 [Info] dotnet finished successfully.
Executing JFrog CLI Command:
D:\Agent01\_work\_tool\_jf\current\jf.exe c remove "<REDACTED> - Test Artifactory Integration_<REDACTED>_dotnet_resolver_1711490010524" --quiet
Finishing: Restore .NET Core Package Dependencies (JFrog)

As you can see, the JFrog Nuget task is missing the /index.json on the end of the URL.

Reproduction steps

  1. Set up a build that multi-targets a solution to build against .NET Framework and .NET (Core)
  2. Add a JFrog Nuget task that restores .Net Framework dependencies for your build
  3. Add a JFrog .NET Core task to restore .NET Core build dependencies
  4. Run the build
  5. Observe the URL output in the build log for each of the tasks. Notice that fro the JFrog Nuget task, the logged URL is missing the /index.json suffix.

Expected behavior

It is expected that the actual URL used to search for packages from the repository would be displayed so that in case there is an issue with package restore, simply using the display URL with the nuget.exe client can help diagnose what may be occurring.

In my environment, this occurred due to the fact that the solution I'm dealing with was using older versions of packages that we did not cache internally and which were now no longer available externally on Nuget.org.

BUT, because the URL that's displayed in the log file is not correct, I got invalid search results (HTTP 404), which lead me to contacting JFrog support and engaging them in a technical call for 2 hours. Not to mention that this whole issue has delayed my project by 2 weeks! (The turn-around time for emails between support is SLOW. Having said that, that's asynchronous communication for you—the support team was wonderful in helping me!)

Azure DevOps extension name and version

JFrog Azure DevOps Extension v2.9.3

JFrog CLI version

2.54.2

Operating system type and version

Windows Server 2019

JFrog Artifactory version (if relevant)

7.63.7

JFrog Xray version (if relevant)

N/A

JFrog Distribution version (if relevant)

N/A

@fourpastmidnight fourpastmidnight added the bug Something isn't working label Mar 27, 2024
@RobiNino
Copy link
Contributor

Hi @fourpastmidnight ,
Sorry for the inconvenience caused by this.

I wasn't able to reproduce this behavior so far:

  1. I'm getting the same result for both NuGet and .NET, both have feeds without the index.json. This is unsurprising, since they use a mutual code to generate the temporary nuget config file.
  2. Trying to access the repository with the /index.json suffix or without it yields the same result, listing the resources (for NuGet repository, not Generic).

Are you using the same JFrog CLI version for both (version 2.54.2 doesn't exist)?
Is it possible that NuGet or .NET modify the presented feed? Perhaps an argument passed with the command?

We could manually add this suffix to sources but we have to make sure that won't have any side effects (suffix added twice, etc).

Thanks

@fourpastmidnight
Copy link
Author

Hmm, OK, since they both use the same code to obtain the URL, I agree, that is strange. But, this is also what I'm seeing. 😕 I'll do some more digging on my end.

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

2 participants