Posts made by alex.giersch_2967

UPDATE:

Initially, we were given an exception to for <Internalsvcaccount>@<domain> account to https://pypi.org/ from our Exceptions.

But we then realized the URL hosting the actual package files is on a different domain: http://files.pythonhosted.org/

One of our developers pointed out that if you open this link: https://pypi.org/simple/ and click on any package it shows you the versions. If you hover on any of those files they are hosted here: http://files.pythonhosted.org/

That seemed to work once we were given the exception to http://files.pythonhosted.org/, but unfortunately we still seem to be having issues. For some packages when I pull them to proget from pypi.org, they seem to get pulled but there is an error which leaves proget in a bad state.

For azure-storage-blob, I can see that ProGet is pulling down the distribution file and putting it on the filesystem. But I think its not working properly as ProGet reports an error, and I can’t pull the package using PIP.

There was an error pulling the package: ProGet only supports wheels and source distribution packages.

The package count in the Python feed rose initially when we gave an exception to the files.pythonhosted.org domain, but since has dropped for some odd reason.

This error has been in our log for some time, but not specific enough to resolve (could be related):

Connector error: Input string was not in a correct format.

We are still working on this.

When doing a "Pull to ProGet" for packages in the feed, we get this error:

There was an error pulling the package: End of Central Directory record could not be found.

We accounted for the Python MIME types as well, adding .whl and .tar and .gz to our types in IIS on the server.

And again when looking at the Connectors section on ProGet, it says PyPi is healthy and the package count is 220,935, but we can't pull, download or promote these packages.

@atripp I will work with my supervisor on working this out. I will get back to you and confirm the solution.

We wanted to check in to get your thoughts on why our internal API endpoint URL addresses are getting caught (404 error) by the proxy:

https://<internalProGet>.<domain>/pypi/PyPI/
https://<internalProGet>.<domain>/pypi/Python/

This is our original request to our internal Exceptions team:

We need to add a Python feed to our test <internalProGet> site for testing a process for potential governance of quant Python libraries.
<internalProGetSVC>@<domain> account needs a proxy exception for https://pypi.org/

This was approved and https://pypi.org/ can be accessed (on the server as well with the svc account). But the API endpoint URLs, which we use to access the PyPi repos on our package repository site doesn’t connect. Errors from <internalProGet> logs:

Connector error: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

But our other feeds, for example, do work:

External: https://registry.npmjs.org
API endpoint URL: https://<internalProGet>.<domain>/npm/npmjs.org/

External: https://www.nuget.org/api/v2
API endpoint URL: https://<internalProGet>.<domain>/nuget/nuget.org/

Just curious if you have seen this before and what we might be missing.

@atripp Thank you for getting back then. Sorry for the delay in response.

Hi Inedo Support,

Two issues just sprung up today.

1. Connector error: The remote server returned an error: (504) Gateway Timeout.

Connector error: The remote server returned an error: (504) Gateway Timeout.
Request URL: https://www.nuget.org/api/v2/FindPackagesById()?id='Microsoft.Extensions.Configuration.Binder'&semVerLevel=2.0.0

2. Unable to update cached data

Unable to update cached data at: https://www.nuget.org/api/v2/FindPackagesById()?id='Generic.Code.Extensions'&semVerLevel=2.0.0
System.Net.WebException: The remote server returned an error: (504) Gateway Timeout.

Currently, we do not have a retention policy on the nuget.org connector feed. What do you recommend we do to resolve this issue?

We are on ProGet version 5.2.9.

--Alex

I ran the full install again and realized it was the cached images in Chrome causing the issue. IE was fine, so I knew immediately it was Chrome.

Thank you again!

@apxltd said in Following up on Previous Ticket - Need info on cause of issue:

Is that what you're looking for?

We had done the refresh post-upgrade, and I had been logged in with my account.

The javascript cache I haven't confirmed. I am going to perform the upgrade again locally and rule out all these factors.

Thanks.

Hi Support,

In a previous support request (EDO-6132). The issue then was as stated below. The All Versions tab wasn't displaying post-upgrade on our local ProGet instance.

Our concern is that this took over a day for those tabs to display the package versions post-upgrade. We cannot move forward in upgrading our Test and Production servers because that down-time is too long for our business. We want to understand why this might happen and if it can be avoided in the future upgrade.

Please let us know what additional details you might need.

Thank you,

Alex

Prior to upgrading our ProGet Prod and Test, we did a local install of our current version (5.1.4) to 5.2.7. Post-install, we cannot find the "All Versions" tab in our packages. On the main Feeds page, it lists the number of packages for each feed and the total number of versions correctly. And we see all the package in the folder directories. Yet we do not see them on the package pages. Are you able to assist?
We list this as minor, but it's a major issue if we cannot upgrade with all versions. We are on a ProGet Basic license.

*names changed in log for security purposes.

We recently added an SSL cert to our ProGet server and set up an HTTPS redirect. When using the NuGet Push step in TFS (pushing to 'https://xtest.wanlink.us/nuget/OurFeed' or any other feed, it fails with the below error. However, it ONLY fails using TFS Git as a source in the build. On ProGet, when putting these URIs in the proxy config test, it indicates success. All accounts are permissioned correctly in ProGet.

Is this a ProGet issue or TFS Git issue?

Pushing SmokeTest.XXXX.nupkg to 'https://xtest.wanlink.us/nuget/OurFeed'...
PUT https://xtest.wanlink.us/nuget/OurFeed
CredentialProvider.TeamBuild: "E:\Agent\CorporateApplications (IL1CABUILD01-TEST)_work_tasks\NuGetCommand_333b11bd-d341-40d9-afcf-b32d5ce6f23b\2.0.24\node_modules\nuget-task-common\NuGet\CredentialProvider
CredentialProvider.TeamBuild.exe" -uri https://xtest.wanlink.us/nuget/OurFeed -nonInteractive -verbosity detailed
CredentialProvider.TeamBuild: URI Prefixes:
CredentialProvider.TeamBuild: https://tfstest/HoldingCompany/
CredentialProvider.TeamBuild: URI: https://xtest.wanlink.us/nuget/OurFeed
CredentialProvider.TeamBuild: Is retry: False
CredentialProvider.TeamBuild: Matched prefix:
CredentialProvider.TeamBuild: This provider only handles URIs from the build's Team Project Collection
Unauthorized https://xtest.wanlink.us/nuget/OurFeed 944ms
System.Net.Http.HttpRequestException: Response status code does not indicate success: 401 (anonymous user not authorized to add packages to this feed).
at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()

Product: ProGet
Version: 5.1.4

We recently applied a retention policy to one of our ProGet feeds, which deletes cached connector packages and removes packages older than 30 days. However, since we applied it this morning, no packages have been removed older than 30 days. We stopped and started the service in Manage Services section with no luck.

Do we need to restart our server hosting ProGet? If so, does this have to be done each time?

Product: ProGet
Version: 5.1.4