Hi @jolaka9284_9458,

Thanks for providing all these details. I was able to pinpoint the reason for the slow down and why it specifically happens on some crates and not others. This is related to some code that we have to determine when to point cargo to pull dependencies from ProGet vs crates.io. Specifically this comes from cargo's API specs for dependencies:

registry — cargo metadata uses a value of null to indicate that the dependency comes from crates.io. The index uses a value of null to indicate that the dependency comes from the same registry as the index. When creating an index entry, a registry other than crates.io should translate a value of null to be https://github.com/rust-lang/crates.io-index and translate a URL that matches the current index to be null.

As you can see, the value specified in the metadata is different than the value the index needs to return. In ProGet, we will return null if the package exists in the feed (including connectors) and https://github.com/rust-lang/crates.io-index if it does not. This is to support the case when ProGet is not used as a mirror and instead for only local crates. Unfortunately the use ProGet as a mirror option is stored only in the client config and is not sent to ProGet.

This is the reason why crates with a lot of dependencies take longer to generate the index than ones that don't and why you'll occasionally get timeouts, but after the retry it works. We have some caching on this to help with performance, but it's not a forever cache.

I'm going to work on some potential improvements for this and will let you know when I have a solution ready. Unfortunately, the only workaround we have for this currently is to use a package approval workflow (like our npm Package Approval blog article).

Thanks,
Rich

Hi @kichikawa_2913,

I have an idea on how to accomplish this. It looks like Docker allows you to expose ports in the run command. Here is what I'm thinking should work. The first thing to do is to map a volume to /usr/share/Inedo/SharedConfig. In my example, I'll map to SharedConfig.

So here would be the steps to try:

1. Create the config file using port 8080

echo '<?xml version="1.0" encoding="utf-8"?><InedoAppConfig><ConnectionString Type="SqlServer">'"`$SQL_CONNECTION_STRING"'</ConnectionString><WebServer Enabled="true" Urls="http://*:8080/"/></InedoAppConfig>' > SharedConfig/ProGet.config

2. run the container using the following command

podman run -d --userns=keep-id -v proget-packages:/var/proget/packages -v  `SharedConfig:/usr/share/Inedo/SharedConfig` -v /etc/pki/ca-trust/source/anchors:/usr/local/share/ca-certificates:ro --expose=8080 -p 8080:8080 --name=proget -e ASPNETCORE_URLS='http://+:8080' -e SQL_CONNECTION_STRING='Server=SERVERNAME;Database=ProGet;User ID=USERNAME;Password=PASSWORD' -e TZ='America/New_York' -i -t proget.inedo.com/productimages/inedo/proget:5.3.32 /bin/bash

Can you please give that a try?

Thanks,
Rich

Hi @viceice,

That error is safe to ignore. It is currently a known bug and we are looking to fix that in an upcoming version of ProGet. The ticket tracking the fix for the log message is PG-1841.

Long story short, the ProGet service correctly detected that the product wasn't activated, and then logged that message. But it was doing it every time it accessed license information, which is on every connector health check, replication run, etc.
Activation happens automatically as soon as someone visits the Web application, and re-activation is required after upgrading certain versions.

Thanks,
Rich

Hi @MY_9476,

Thanks for bringing this to our attention. I added a ticket, OT-502, to fix the issue. This should be released next week in Otter 2023.2.

Thanks,
Rich

Hi @mwatt_5816,

Thanks for all of the detail. I have fixed the code, BM-3982, for this template and it will be released in the next maintenance of BuildMaster 2024.0.7 on Friday.

Thanks,
Rich

Hi @jeff-peirson_4344,

I have been able to recreate the issue and created a ticket, PG-2870, to track the fix. We expect this to release in ProGet 2024.25 on January 24, 2025. This looks to be related to the package name existing on npmjs.org with all versions being unlisted. If you need a fix sooner, we can provide a pre-release version of ProGet 2024.25 that includes the fix.

Thanks,
Rich

Hi @gravufo,

Would you be able to rerun the database scripts on your database? You will just need to run the Run inedosql to update the database step of our manual install guide. Can you see if this fixes your issue?

Thanks,
Rich

Hi @gravufo,

Great! Glad to hear it! Please post back if you find anything else.

I also recommend that you switch to the Inedo Hub in the future. We are in the process of deprecating our traditional installer. The Inedo Hub has the ability to update an installation previously installed with the traditional installer and the Inedo Hub now supports offline installations as well, if you need that functionality.

Thanks,
Rich

Hi @markus4830,

I'm definitely sorry about this. The change was made to help to aide in improvements to other areas of the system related to NuGet. Unfortunately, it looks like it affected the NuGet API. Expect a more permanent solution in the near future.

Thanks,
Rich

Hi @mcascone ,

We have fixed the issue and the published date will now update when the package is overwritten. This will be released in ProGet 5.3.9 which is due out this Friday Augst 14, 2020.

Thanks,
Rich

Hi @nuno-guerreiro-rosa_9280,

We have finally been able to recreate this issue in our sandbox. We are currently looking into a fix, but we expect to have one in the next version of ProGet, 5.3.10. This looks to be an issue with the mono framework. We use mono runtime in our Docker images for ProGet. We are also going to be releasing a .Net Core based technical preview of ProGet Docker in version 5.3.10. This will be in addition to our standard mono based version. Our internal testing is going very well and it looks to have removed a lot of the gotchas that mono has.

Thanks,
Rich

Hi @viceice,

Thanks for the clarification on your environment! I see what is going on now. I have created a ticket, PG-1809, to track the fix for this. We expect this to be released in ProGet 5.3.11 which we are expecting to be released in September 11, 2020. Basically in that instance, we are not respecting the values within the X-Forwarded-* headers. I'll let you know if anything changes on the timeline.

Thanks,
Rich

Hi @mcascone,

Sorry about that. I'll get that backported to ProGet 5.3 also. This will be tracked in ticket PG-2074.

Thanks,
Rich

Hi @barnaby-williams_8489,

Please see our documentation for cloud storage. There is a subsection for migrating a feed to cloud storage.

Thanks,
Rich

Hi @NUt ,

Thank you for bringing this to our attention. This bug, PG-2126, will be fixed in ProGet 6.0.12. Going forward it will allow you to configure everything and even test it via the "Test User Directories" button, but it will only allow you to login using the Built-In user directory and the username/password login option when using ProGet free.

Thanks,
Rich

Hi @toni-wenzel_6045,

Currently, the only way to set the description would be to do it using the UI or the Native API. In order to set it using the Native API, you would need to do the following:

First, Get the Docker Repository ID by making a GET request to <Base URL>/api/json/DockerImages_GetRepositoryByName?key=<API Key>&Feed_Id=<Feed_ID>&Repository_Name=<Repository Name>
This will return a list of images (should only be 1 in the list) and you will need to get the DockerRepository_Id from each item.

Then, you will need to POST a JSON object to <Base URL>/api/json/DockerImages_CreateOrUpdateRepository.
The JSON object you would post would be:

{
	"API_Key" : "<API Key>",
	"Feed_Id": "<Feed Id>",
	"DockerRepository_Id": "<ID from previous request>",
	"Repository_Name": "<Repository Name>",
	"RepositoryIcon_Url": "<Icon_URL>",
	"ShortDescription_Text": "<Short Description>",
	"FullDescription_Text": "<Full description (Readme.md)>"
}

Please note that you will need to populate all of the values. For example, if you do not populate the RepositoryIcon_Url, the value will be cleared.

Thanks,
Rich

Hi @philipp-grathwohl_1687,

Currently, the only way to set the description would be to do it using the UI or the Native API. In order to set it using the Native API, you would need to do the following:

First, Get the Docker Repository ID by making an HTTP GET request to <Base URL>/api/json/DockerImages_GetRepositoryByName?key=<API Key>&Feed_Id=<Feed_ID>&Repository_Name=<Repository Name>
This will return a list of images (should only be 1 in the list) and you will need to get the DockerRepository_Id from each item.

Then, you will need to HTTP POST a JSON object to <Base URL>/api/json/DockerImages_CreateOrUpdateRepository.
The JSON object you would post would be:

{
	"API_Key" : "<API Key>",
	"Feed_Id": "<Feed Id>",
	"DockerRepository_Id": "<ID from previous request>",
	"Repository_Name": "<Repository Name>",
	"RepositoryIcon_Url": "<Icon_URL>",
	"ShortDescription_Text": "<Short Description>",
	"FullDescription_Text": "<Full description (Readme.md)>"
}

Please note that you will need to populate all of the values. For example, if you do not populate the RepositoryIcon_Url, the value will be cleared.

Thanks,
Rich

Hi @harald-somnes-hanssen_2204,

The fix is scheduled for release in ProGet 5.3.16 which is due out on Friday. I'll reply back if anything changes.

Thanks,
Rich

Hi @antony-booth_1029,

Starting in version 6.2.21, we actually made a new variable function to create the URL for you. You can use the $BuildMasterUrl(build) function and that will generate the URL. If you are running that from within the context of a build, you will not need to specify any other parmaters. You can see more about its usage in the functions reference in BuildMaster by navigating to Administration -> Reference Documentation section -> Functions. We have also added a $BuildMasterId function if you need to get the BuildId directly.

Hope this helps!

Thanks,
Rich

Hi @kichikawa_2913,

I think I have identified the issue. I have just pushed another version of InedoCore, version 1.10.7-CI.2 . Could you update and give that a try? I also added an option to bypass the LDAPS certificate verification. It is something that I would only use while testing. The solution you have with adding your certificates as valid certs is a more secure solution. One last thing to make sure you set is the Domain Controller Host. It can just be set to your domain (ex: domain.network using your steps from above). Linux/Docker does not seem to translate domain URLs the same way windows does.

Thanks,
Rich