Posts made by thoven

Thanks Philipe; all operation documentation is automatically updated within the software once the latest version of the relevant extension is installed (i.e. the Windows extension in this case). The documentation on the website will also get updated with any minor version of the software is released, or the Inedo.SDK is updated.

Hope this helps,
-Tod

As a followup, support for the Portable PDB format in the symbol/source server has since been added to ProGet.

The Active Directory user directory has since been open-sourced here: https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/InedoExtension/UserDirectories/ADUserDirectory.cs

This appears to be an issue with the TFS credentials provider - the 401 status code means credentials were not supplied (and the error message confirms that as well); but typically clients should followup with a 2nd request that includes credentials when the 401 is received.

If credentials are actually sent and are invalid/forbidden, then a 403 would be returned by ProGet.

This can occur if the username/password credentials for Git are invalid, or more commonly, if a Git raft is configured as read-only (which probably doesn't require authentication e.g. GitHub) then is reconfigured to support write operations.

As a followup, it's worth mentioning that this occurs specifically when directory providers are switched. The "Active Directory (New)" user directory requires the user@domain.tld format, so switching from the previous "LDAP & Active Directory" user directory (which supported netBIOSdomain\user) no longer can impersonate.

Thank you for the report; this will be resolved by the following issue: BM-3364

Hi Bret,

A tutorial for TeamCity is here: https://inedo.com/support/tutorials/buildmaster/teamcity/choosing-specific-artifact-from-teamcity

Future note, the TeamCity tutorial may be moved to https://github.com/inedo/inedox-teamcity/wiki as part of a docs re-organization.

As for controlling Apache, this is done through the httpd command, which can be executed with an Exec operation in your deployment plans, e.g.:

# Deploy to Apache
{
    Exec httpd -k stop;

    # deploy artifacts...

    Exec httpd -k start;
}

Are you granting "Anonymous" the permission to view/download packages? If you remove that from the User Tasks page, then authentication would be required.

To use script assets, use the CollectScript and/or ConfigureScript properties, for example:

# ensures the BuildMaster Agent service exists on the remote server, using a
# PowerShell script asset to perform the configuration
PSEnsure(
    Key: BuildMasterAgentInstalled,
    # returns the count of INEDOBMAGT services installed
    Collect: @(Get-Service | Where-Object {$_.Name -eq "INEDOBMAGT"}).Count,
    # expected value is 1
    Value: 1,
    # use script stored in InstallBmAgent asset
    ConfigureScript: InstallBmAgent,
    ConfigureScriptParams: %(
        AgentType: TCP,
        Port: 1000),
    Debug: true,
    Verbose: true
);

If the ProGet version you listed (5.1.23) is accurate, it should already just work. ProGet will send a 403 if the user performing the push does not have overwrite permission, which I would assume fail the task.

Is it possible you are authenticating with a different user, or that Anonymous has overwrite privileges?

I believe this issue was resolved in ProGet v5.1.23 as part of PG-1462

The steps are outlined here: https://inedo.com/support/documentation/proget/advanced/cloud-storage

You can safely do all of those things :)

I don't know what else to say, I can't reproduce this anywhere.

Here's a feed that simply has a connector to the same NuGet URL: https://proget.inedo.com/feeds/ExternalBuild and when I search it, the first result is System.Text.Encoding.CodePages 4.6.0-preview3.19128.7 with the other results just below it.

ProGet will display warnings within the software 2 weeks before the expiration date, then it will stop working upon expiration.

You are permitted to request a stopgap key in the meantime to avoid service interruption as per: https://inedo.com/support/documentation/various/licensing/management#stopgap

ProGet only returns the package IDs, once you click on that, the Versions tab will have all the versions.

Please refer to: https://inedo.com/support/documentation/proget/installation/config-files

How are you searching for them? If I searchCodePages in the ProGet UI, it's the first result (albeit the pre-release version is returned).

If you are using some other means to search (i.e. Visual Studio) that is also dependent on the .NET Framework version of the project you're searching against.

What is the actual error? ProGet returns extra status information with any errors. Also, can you download it from the ProGet UI? The download link button there should be the same as the one used by Visual Studio.

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.

These will be included in the next maintenance release as per this issue: PG-1406

You can download the latest (v41 at the time of this post) from here: https://inedo.com/support/documentation/inedoagent/versions

PowerShell converts 10GB into 10737418240 - OtterScript doesn't do this automatically, you'd have to do $PsEval(10GB) if you wanted the equivalent, but it's best to just put the number in directly I would think.

You could use the Variables Management API for this:

https://inedo.com/support/documentation/otter/reference/api/variables

We cannot reproduce this behavior.

How are you verifying that the older package isn't in the feed? Note that the Feed Overview page only lists the latest version, you have to browse to the versions tab once you select that package to actually see all the versions.

Thank you for the report; it looks like the extension was migrated correctly but never officially released to our extension feed...

I'll have someone release it ASAP

A 401 means that npm requires authentication which was not supplied, visit Feeds > Connectors > [edit/create npm connector] and enter a username/password to connect to the external registry.

This was resolved in the latest release of Otter (v2.0.12 at the time of posting).

This is configured in: Admin > Change User Directory (LDAP) > Advanced > Active Directory (New)

There are ways to test/debug on that page as well.

These are available on the All Versions page: https://inedo.com/proget/versions