PaketUpdate fails with semver 2.0 version and jfrog hosted repository #3601
Comments
|
/cc @matthid @enricosada |
|
Considering paket |
|
@matthid it seems to be listed in the AllVersions endpoint |
|
|
|
I will try an older version and report back. |
|
Same issue with |
|
Hi, we still see this issue with paket + artifactory + semver 2.0 :) |
|
I also experience this problem. I think the real source is a bug in Artifactory (6.11.6 here), but it's only triggered by Paket, not by nuget.exe. At first, nuget.exe and paket do the same thing: GETing I don't know, however, why paket tries to get the individual entry again, as the complete entry is already in the feed returned by This is what nuget does: And here what paket does: Then paket (heuristically?) tries out a few other REST calls, all resulting either in 404 or 405 ( |
|
is there some open endpoint that I could look at? |
|
There is an "Open Source Edition", which you can pull directly via docker, but as I understand their comparison matrix, it does not support nuget. |
|
I think I have found a corresponding bug report at JFrog: API calls for certain NuGet packages are returning 404 |
|
I found that Note the When you specify the version without build-metadata (e.g. |
|
After some ping-pong with the JFrog support I got the confirmation that it's a known issue and supposed to be fixed in Artifactory 6.14. |
|
Can anyone of you confirm that the semver2 issue is fixed with Artifactory-6.14? I'm asking because we tested again with v6.15 and the issue is still exists here. JFrog confirmed again that "the issue is not fully fixed", but they are working on it and expect the fix to be available with the next Major. Now, how do we proceed with Paket then? This effectively means that Artifactory-6 does not support SemVer2, despite their claims (at least with the v2 protocol). It only works somehow when using nuget.exe because nuget.exe performs some fall-back (the initial request fails, too). Basically I see two options:
Unfortunately I don't have the resources right now to help implementing this :-( |
|
There is no public server to repro, right?
jbaehr <[email protected]> schrieb am Do., 21. Nov. 2019, 10:53:
… Can anyone of you confirm that the semver2 issue is fixed with
Artifactory-6.14? I'm asking because we tested again with v6.15 and the
issue is still exists here. JFrog confirmed again that "the issue is not
fully fixed", but they are working on it and expect the fix to be available
with the next Major.
Now, how do we proceed with Paket then? This effectively means that
Artifactory-6 *does not* support SemVer2, despite their claims (at least
with the v2 protocol). It only works somehow when using nuget.exe because
nuget.exe performs some fall-back (the initial request fails, too).
Basically I see two options:
1. Address #3638 <#3638> and
see whether the *v3 protocol* is affected, too. (On that front, Paket
is to blame, not Artifactory.)
2. Implement the same kind of fall-back that nuget.exe performs on the *v2
protocol*, i.e. getting the individual package metadata from the
FindPackagesById end-point if Packages fails (cf. my comment above
from 2019-10-31). This could also reduce the number of network round-trips
if paket would cache the first FindPackagesById response (cf. my comment
above from 2019-10-22). I haven't looked deeper into the code, but at the
first glance it seems that paket remembers only the package versions from
the FindPackagesById call and later fetches the other metadata over the
Packages endpoint. If paket would remember the whole metadata (not only the
version), we could eliminate this additional network request.
Unfortunately I don't have the resources right now to help implementing
this :-(
It seems we have to stay with semver1 for some time... again.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3601?email_source=notifications&email_token=AAAOANAXHD2EG2WDYQGWZ5LQUZLA5A5CNFSM4H254GGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZUBQI#issuecomment-557007041>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAOANHU5MGWCLYA5XH3ISLQUZLA5ANCNFSM4H254GGA>
.
|
But fortunately the problem here is not about parsing some freaky response, but simply getting an HTTP-404 where an answer should be. (And even this answer was already send as part of the |
|
I'd really love to help but I'm totally lost without a repro. |
|
@forki I need to double check with my manager. But if it helps I could create a public virtual repo on our instance and set it to pull from nuget gallery if this helps? Even better if the access could be limited as the traffic costs could explode. |
|
That would be awesome.
Manfred Endres <[email protected]> schrieb am Do., 21. Nov. 2019,
16:02:
… @forki <https://github.com/forki> I need to double check with my manager.
But if it helps I could create a public virtual repo on our instance and
set it to pull from nuget gallery if this helps? Even better if the access
could be limited as the traffic costs could explode.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3601?email_source=notifications&email_token=AAAOANBFRC23QQMVGOAVJWTQU2PHZA5CNFSM4H254GGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE2QR2Y#issuecomment-557123819>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAOAND3NDST3GDOBPHA4W3QU2PHZANCNFSM4H254GGA>
.
|
|
ok thanks to @Larusso I can now reproduce. The problem is I have no idea what to do. We try 9 different URLs to get package details. All of them are returning 404 or even 405. This is a artifactory issue. They need to check why their system is returning 404 for Regarding NuGet. It seems they just download the package when they can't get metadata. That's a weird approach and I don't think we should go this route. |
|
@forki thanks for looking into this! |
|
can someone add someone from artifactory into the discussion? |
Well not too weird. You can download and inspect the nuspec to get the metadata as well :D |
|
This is actually what you have to do when your source is a simple nupkg storage (like a local directory is) Edit: I wanted to add that there is no doubt that artifactory is broken ;) |
|
it's weird in the sense that we create a lot of traffic and waste on devs machines |
|
The flow that @matthid describes sounds more like how maven works. So yes why all the fuzz with metadata fetching when you also could start of with a basic brute force download. But one thing to remember with jfrog is that you are able to reconfigure the repository layout. I never touched this option but it's possible ;) |
|
@Larusso Paket has > 2000 version and FAKE > 1700. If you hit such packages AND run into version conflict trouble so that it wants to check many many version then this can easily become very unpleasant |
|
@forki We had already some |
Indeed. But what about this (see also my comment above): The assumption here is that It seems that nuget.exe behaves differently, depending on whether you request an explicit version or not:
|
|
@Larusso your v2 sample now works for me. Weird. Can you please retry with "paket install --force"? |
|
Yeah that is strange. |
|
Did you try --force?
Manfred Endres <[email protected]> schrieb am Fr., 29. Nov. 2019,
16:40:
… Yeah that is strange.
Worked for me as well. But I broke it again by publishing a 2.0.0-rc.1.
I had this issue also before while testing a couple of month ago. This was
also the reason I started to switch to semver2 because my initial tests
worked.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3601?email_source=notifications&email_token=AAAOANHPLKU4R4GH77NW4UTQWEZYBA5CNFSM4H254GGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFPEPKI#issuecomment-559826857>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAOANGT3QLTJ26H5TZ75FTQWEZYBANCNFSM4H254GGA>
.
|
|
Yes I did. |
|
potential fix in #3739 |
|
@Larusso I released a new version yesterday. Can you please check if it works? |
Description
We use paket to install our internal dependencies from a jfrog SAS installation. We started to use semver 2.0 versioning and had no issues until recently.
We need to force a specific version which is not compatible for testing purposes but paket throws errors:
Couldn't get package details for package Wooga.Core 4.1.0-branch.pr.34.5 on https://foo.jfrog.io/foo/api/nuget/nuget. - 2_https://foo.jfrog.io/foo/api/nuget/nuget/Packages?$filter=(tolower(Id) eq 'wooga.core') and (Version eq '4.1.0-branch.pr.34.5'))r.34.5')I tried to set the feed URL to
v3but get:could not find an AllVersionsAPI endpoint for https://foo.jfrog.io/foo/api/nuget/v3/nugetIt looks like the switch doesn't work correctly: #3351
Repro steps
This is quite hard because I think the issue lies with jfrog here.
In the dependencies file we set
The text was updated successfully, but these errors were encountered: