Schedule Triggers haven't been replaced; we only really consider those legacy because of the way the variables are handled by them.

See also: https://inedo.com/support/questions/9736

You may need to enable their visibility via Admin > Advanced Settings > Legacy.ScmTriggers

In the UI, they are under the "Legacy Build Triggers" tab as of 6.1, replaced by Repository Hooks & Monitors (under Builds).

Make sure to set the Web.BaseUrl setting in Admin > Advanced Settings as well.

We don't have one yet (we're working on the documentation now, expected for the official 5.2 release), but there are examples in ProGet itself for:

• adding packages: click the Add Package button on the feed overview page after you've added one
• installing packages: once you have a package in a feed, browsing to it will show you how to install it with pip

You can try setting a drop path for each feed to a temporary directory, then copy the packages into that directory.

FYI I believe they need to be in that directory directly and not in a subdirectory.

You can trigger the drop path monitor manually from Admin > Manage Service if it doesn't run right after copying.

There was an issue (PG-1208) with semantic version-enabled NuGet feeds and retention policies fixed in v5.0.8 - an upgrade should resolve this.

Here are the features by edition: https://inedo.com/support/documentation/proget/administration/license

ProGet Free is allowed for companies, however that edition only receives "community support" (i.e. this forum).

Yes, that is OK, the differences for each edition are outlined here: https://inedo.com/support/documentation/proget/administration/license

That operation will be remoted to the server in context, so in your case, Production. Are the SQL Server services are running on the remote machine? Are you certain the connection string is correct? Oftentimes the instance name is missing e.g. Data Source=prod.db-01\SQLEXPRESS;Initial Catalog...

nuget should not be anywhere in the URL; that's meant to be the endpoint for NuGet feeds. If it's displayed somewhere, that's a UI glitch that has since been fixed.

The correct command is:

gem push <gem file> --host http://{proget-host}/rubygems/{feedName}

If that's the command that gave you endpoint not available, is there a way to add even more verbose logging to say which endpoint it's referring to? We've probably added it since v4.7.1 (search for ruby on this page: https://inedo.com/proget/versions for specific bugs fixed)

Unfortunately this was a regression present in 5.1.19, but has since been fixed in 5.1.20 which was released earlier today.

Hello Simon,

I wasn't able to find any information on any standardized way to designate a license in a Dockerfile. I believe the license field in the Docker image pages in ProGet is not filled in by anything.

Hello Philippe,

The visual editor losing module namespaces is OT-273, which is fixed in Otter 2.1.2.

This is also fixed (BM-3271) starting in v6.1.0

Are you actually on v2.1.1? This should have been fixed as part of OT-238 in 2.0.10

Assuming you are using the Deploy Package endpoint, you will receive a deployment id back as part of the return object. In your powershell script you could implement a "busy wait" where you check for the status of the deployment you kicked off by passing in the deployment id to the Get Deployments endpoint. If the status property is pending or executing then sleep for a few seconds and try again. You would also want to include some sort of maximum number of tries before failing the powershell script.

Apparently this was updated in BuildMaster but not Otter, here is the documentation for the updated version that also applies to yours, substituting $CredentialProperty for $GetCredentialProperty:

# ProGetCreds is an instance of Inedo Product Credentials (i.e. InedoProduct::ProGetCreds) with 'Allow encrypted properties...' checked

set $key = $CredentialProperty(ProGetCreds, ApiKey);
set $host = $CredentialProperty(ProGetCreds, Host);

Log-Debug Getting ProGet package from $host with API key: $key;

ProGet::Get-Package(
    Credentials: ProGetCreds,
    Feed: hdars-1k,
    Name: hdars,
    Directory: $WorkingDirectory
);

Additionally, I will notify our product director to add an issue to fix this in Otter (it would still be backwards compatible, but the canonical name would become $CredentialProperty)

ProGet v5.1.16 was just released with the fix included

Are you pushing the same version number? If so, this is (unfortunately) a by-design feature of NuGet.

The solution is to use pre-release versioning, or instruct the NuGet task of the build server to always request with the -NoCache flag.

Please see: https://inedo.com/support/documentation/various/ldap/troubleshooting#privileges-not-working

In short, in Microsoft's AD implementation, Domain Users is not returned as part of the memberOf LDAP property.