In v5, Docker feeds are now under "Containers" in the main navigation.

If you want developers to always be able to use any version of a package, then you should configure a connector to that remote resource. Then, they will always be able to download the latest version of the packages they need, and ProGet will cache those packages.

There is currently no such healthcheck URL; you could use a static resource (like a logo, /resources/images/layout/logo.svg) to see if the web server is responding. That request should be very fast.

UPDATE: this was resolved through our ticket-based support. The underlying issue was "Unable to reach credential server" s3, and it was related to how the credentials were configured in IAM.

Great idea :) See BM-3278

Just to clarify, you can create releases on the "Releases" tab, just "Create New Release". You can have multiple simultaneous releases per application going on, which is ideal for a scenario you describe

Yes! You can use either NuGet or Universal Packages to store your C++ code and packages, and those host those in ProGet.

Keep in mind that retention rules work on an AND basis, so when you select: Delete cached connector packages Delete old versions (all except latest 30 versions) You get only packages that match BOTH of those rules: Only delete cached packages. Never delete the most recent 30 versions of packages. I'm guessing that your packages don't match BOTH those rules;

Ticket is submitted along with additional information

ProGet does not push packages; but you can use a tool like BuildMaster to help build a pipeline for your own nuget packages, and push to different nuget servers along the way.

Could this be related to Quirks mode? https://inedo.com/support/documentation/proget/feeds/nuget#legacy

I finally bypass this limitation by using adding an argument to the module

This problem was linked to https://inedo.com/support/questions/9521

I ended up using powershell to add variables to a properties file of env.properties. Then used the "inject environment variables" post build step to add the file with those variables to by environment. #Powershell "APP_VERSION=$appVersion RELEASE_NUMBER_VAR=$releaseNumber IIS_APP_ROOT_NAME=$iisAppRootName APP_EMAIL=$appEmail" | Out-File env.properties -Encoding ASCII Then then used the Get-Release API to check and see if my selected release was a valid release. If not I created it with the Create-Release API. Then used the Inedo_BuildMaster Plugin for jenkins. Create BuildMaster Package - Post Build Step Variables: appEmail = ${APP_EMAIL} appVersion = ${APP_VERSION} buildNumber = ${BUILD_NUMBER} buildType = ${BuildTypeParam} iisAppRootName = ${IIS_APP_ROOT_NAME} iisHostNamePrefix = ${BuildTypeParam} After I figured out myself how to inject the Variables and use them properly this rout was much better because it let me know when the package was done deploying, if it failed, showed me the deployment log on failure and failed my Jenkins Job on Failure. Thank you for your answer though Josh!

I'm sorry but I'm not understanding what you mean by "queues" or "hangfire"...

There was a UI change; these are listed under "Containers" in the top UI.

Please note that retention policies are a paid feature. Although rules can still be configured in the free edition, they are always executed in dry run mode in ProGet Free. In addition, when multiple options are specified, then only packages that meet all of the selected criteria are considered. Please review the retention rules for more information Otherwise, the best place to look would be the retention logs, to show you what packages were considered.

My workaround for supporting scripts and modules is to essentially trick it. either specify the source and script source with the fqdn version of the url and then a shortversion of the url or, what I do, set up a iis front end for redirect urls. i.e. if your server name was repos and your domain was mycompany.com then you might set source to repos.mycompany.com:8624/nuget/myrepo and set script source to repos:8624/nuget/myrepo You can list and publish scripts or modules to the same repo and find-script will differentiate from within the repo. The more elegant solution, but more difficult, is to create a dummy website with real or virtual paths that use http redirects to the right sight. So you could set your source to something like repos.mycompany.com/source and that folder would redirect to the path on the different port. That's just a quick summary of the workaround, I realize that, I can provide more thorough examples if you would like.

There have been no changes to the way our products connect to databases in many years, so this is unrelated to an upgrade. However, it seems to be some sort of indication that SQL Server must be overloaded, or a network problem. This can typically be diagnosed / reviewed by the SQL Server DBA, who can see incoming connections, and which queries are taking too long, etc. But in my experience, just restarting the server you have SQL Server installed on fixes it like 80% of the time.