You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
As you can see, the JFrog Nuget task is missing the /index.json on the end of the URL.
Reproduction steps
Set up a build that multi-targets a solution to build against .NET Framework and .NET (Core)
Add a JFrog Nuget task that restores .Net Framework dependencies for your build
Add a JFrog .NET Core task to restore .NET Core build dependencies
Run the build
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
The text was updated successfully, but these errors were encountered:
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.
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).
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.
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 usingnuget.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:
Here's the similar output at the end of the build log for the (correctly logged) JFrog .NET Core task:
As you can see, the JFrog Nuget task is missing the
/index.json
on the end of the URL.Reproduction steps
/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
The text was updated successfully, but these errors were encountered: