Posts made by thoven

Is this user a direct member? If not, you need the latest InedoCore extension (v1.0.8 as of a few minutes ago) and make sure to enable recursive search in its advanced configuration.

Make sure to delete the C:\ProgramData\upack directory as well

This is a small bug in the extension (it identifies as a different version than it was released as) that occurred during an internal transition... each of those 2 extensions will no longer show as "update available" once their next versions are released.

As far as I'm aware, the original issue in this thread has been resolved long ago.

If there is a new issue with pulling connector packages, please post a new question.

This took a while to track down, but that error message is ultimate caused by having an extension that fails to load along with a value set for Extensions.BuiltInExtensionsPath, and the error message will be fixed as part of issue: ILIB-52

However, this error is only generated when the extensions manager is initialized, which occurs when the integrated web server (or IIS application pool) is restarted. This means that either the timeout you're experiencing causes the website to restart, or the timeout is caused by the web server restarting.

You could try setting Diagnostics.MinimumLogLevel to 0 temporarily to get debug logging, or examine the Windows Event Log to see if there are any .NET errors that cause the web application to restart.

Make sure the following configuration values in Admin > Advanced Settings are set to an accessible directory (note that the defaults from the installer are shown here, double-check that they are valid in your installation):

• Extensions.ExtensionsPath - C:\Program Files\ProGet\Extensions
• Extensions.ServiceTempPath - C:\ProgramData\ProGet\ExtensionsTemp\Service
• Extensions.WebTempPath - C:\ProgramData\ProGet\ExtensionsTemp\Web

The connection string is in a different place yes, but unless you changed it from the value it was, that shouldn't affect timeouts.

My guess is that the SQL Server service just needs to be restarted.

Is your feed configured to strip symbols and/or source code from the package?

The tracking issue for this is here: PG-1337

Please refer to the Upgrading Extensions section of the v6.0 upgrade notes.

I was finally able to go through the source code to see that the menu option was in fact missing in v1.0.3 - I don't know how I missed that you were on that version vs. the one I was using (v1.0.4) :(

An upgrade would solve, but I also see your ticket and will prod a developer to take a look at that for you as well and get out a new hub installer with the improved debug logging.

For the Windows service, the only requirements for the service account are (assuming default file system package store configuration) read/write access to the directory where the underlying packages are stored (default is in ProgramData), read/write access to the service installation directory (default is in Program Files), and granted access to the ProGet database role named ProGetUser_Role.

For the web application (Windows service or IIS application pool identity), the requirements are the same as the Windows service, plus read/write access to the website installation directory.

Note again that the Desktop Hub installation privileges is orthogonal to the account that ProGet runs as, since it would obviously require more privilege to create/update/grant in the database and also create subfolders in Program Files & %ProgramData%. As an extra word of caution, if D: is a mapped drive, be sure to use the full UNC path in configuration settings within ProGet.

There should be an official v1.0.0 version released with that exception fixed. Before attempting to install it, manually delete Artifactory.* from your Extensions path ({InstallDir}\Extensions) .

Apparently our public ProGet instance did not grant anonymous view access to that asset directory... should be visible now.

Here is what I mean:

In the context of a project, the Admin > Project Settings menu option will take you to the page that has the Delete option.

I've been looking into this further, I cannot figure out where you download this extension because as far as I can tell, we have never released it. I know we went through a transition in our deployment process for these internally as of BuildMaster v6.0, but there is no indication of this extension available on the Inedo Den or on the public ProGet extension feed.

Did you build this extension yourself?

In the meantime I will have one of our engineers release this officially.

It autocomplete/dropdown uses Username & Password credentials for the Package Source URL.

I also agree, that it should support both or at least be clear which type it's using :)

The tracking issue for this is here: HH-17

There are two ways to ensure that value is populated, either wrap the operation/plan in a general block, e.g.:

for server MyServer
{
   # ... Copy-Files...
}

or edit the pipeline stage target to target a specific server (which effectively wraps the whole plan in that block transparently).

I am not sure how it could have worked before... it's possible that there was an implicit fallback to the local server (or server ID #1) in the v4 version.

If you need to supply credentials when connecting to the domain, make sure "Specific list..." is selected, and enter it as:

domain.local,CredentialName

Where CredentialName is the name of set of Username & Password resource credentials created via Admin > Change User Directory > Advanced > AD Credentials > Create

What version of the Artifactory extension do you have? This can be found on the Admin > Extensions page.

Under Admin > Resource Credentials, is there a saved Artifactory set of credentials named "repo" with a base URL, username, and password all filled in?

Also, the operation text has the Credentials property listed twice, remove one of them.

I will also have someone put a note in to fix that error message since it's not particularly helpful :)

You can actually put a full commit ID in the Tag field (which actually supports any refname)... I'll have someone put a note in to change that in the operation.

It's possible there is a redirect error with the built-in authentication.

Can you visit the log-in URL directly, i.e.: http://{bm-server}/log-in and enter Admin / Admin (assuming a fresh install), and see what page you're being redirected to that requires Administrator privileges?

My initial guess is a bad/missing license key...

I am not aware of any good way to interact with the GUI while running as a service, at least not since Windows Vista.

There is "Kiosk Mode", is that what you're looking for?

Does the public IP actually resolve to to that server internally?

Only other thought is that it's an HTTP URL reservation issue (maybe localhost was explicitly registered instead of * somehow). You can check by running the following from PowerShell:

netsh http show urlacl | ?{ $_ -like "*:8624*" }

Copying from associated support ticket:

It's not a bug per se, more of a design flaw with the introduction of external package stores. Basically, it checked to see if the package could be opened and if not, deleted it from the DB. However, there are many reasons a package might not be accessible (network down, invalid S3 credentials, disk inaccessible, S3 down, etc.), so this functionality was removed since then.

ProGet supports Unicode so there is no reason it shouldn't work.

When adding directly to the DB are you using the N'test 팀' syntax (specifically the prepended N) to indicate NVARCHAR?

Here are the possible reasons for reactivation: https://inedo.com/support/documentation/various/licensing/activation#re-activation

I'm guessing it's related to TLS v1.2:

https://inedo.com/support/questions/8831

It's possible it may work (I can't verify) if you specify the port in the domain controller host value under advanced settings (i.e. enter your-dc-server:636 as the value).

See the LDAP Advanced Settings documentation for info on how to find that page to configure that value.

If that doesn't work, I suspect a code change is needed - it is not clear via the Microsoft documentation what the default AuthenticationType is for this call: https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/InedoExtension/UserDirectories/ADUserDirectory.cs#L268

Try the following code; it removes the need for IGenericBuildMasterContext altogether and uses an async method to replace the Task.Run call:

    public override async Task ExecuteAsync(IOperationExecutionContext context)
    {
        // Clone Repo to directory
        CloneOptions co = new CloneOptions();

        co.CredentialsProvider = (_url, _user, _cred) => new LibGit2Sharp.SecureUsernamePasswordCredentials { Username = Username, Password = Password };

        var path = context.ResolvePath(CloneTo);

        path = Repository.Clone(Path.Combine(BaseUrl, RepositoryName), path, co);

        // Get Commit hash
        var repo = new Repository(path);
        var commitHash = repo.Head.Tip.Sha;

        // Get local + remote branch names
        var localBranchName = "refs/heads/" + Branch;
        var remoteBranchName = "refs/remotes/origin/" + Branch;

        Log(new SimpleLogMessage(Inedo.Diagnostics.MessageLevel.Debug, $"Local Branch set to {localBranchName}", "Git", "", context));
        Log(new SimpleLogMessage(Inedo.Diagnostics.MessageLevel.Debug, $"Remote Branch set to {remoteBranchName}", "Git", "", context));

        // Check the remote branch exists
        var trackingBranch = repo.Branches[remoteBranchName];
        if (trackingBranch == null)
        {
            Log(new SimpleLogMessage(Inedo.Diagnostics.MessageLevel.Error, $"Branch {Branch} does not exist on the remote.", "Git", "", context));
            throw new Exception($"Branch {Branch} does not exist on remote");
        }

        // Checkout branch
        Log(new SimpleLogMessage(Inedo.Diagnostics.MessageLevel.Debug, $"Creating Branch {Branch} Locally", "Git", "", context));
        Branch localBranch;
        try
        {
            localBranch = repo.CreateBranch(Branch, trackingBranch.Tip);
        }
        catch
        {
            // Branch already exists - set it up
            localBranch = repo.Branches[localBranchName];
        }

        Log(new SimpleLogMessage(Inedo.Diagnostics.MessageLevel.Debug, "Tracking remote branch", "Git", "", context));
        repo.Branches.Update(localBranch, b => b.TrackedBranch = trackingBranch.CanonicalName);

        Log(new SimpleLogMessage(Inedo.Diagnostics.MessageLevel.Debug, "Checking out branch", "Git", "", context));
        Commands.Checkout(repo, Branch);
        Log(new SimpleLogMessage(Inedo.Diagnostics.MessageLevel.Debug, $"Cloned branch {Branch} Successfully", "Git", "", context));

        // If hash is specified, checkout that
        if (!string.IsNullOrWhiteSpace(Commit))
        {
            Log(new SimpleLogMessage(Inedo.Diagnostics.MessageLevel.Debug, $"Commit Hash set. Attempting to checkout commit hash {Commit}", "Git", "", context));
            repo.Reset(ResetMode.Hard, Commit);
        }

        // Make sure the commit hash is set correctly
        commitHash = repo.Head.Tip.Sha;

        Log(new SimpleLogMessage(Inedo.Diagnostics.MessageLevel.Information, $"Cloned Successfully: Hash is {commitHash}", "Git", "", context));

        // Set commit hash 
        if (String.IsNullOrWhiteSpace(VariableName))
        {
            Log(new SimpleLogMessage(Inedo.Diagnostics.MessageLevel.Information, "No Commit Hash Variable Specified. Not setting.", "Git", "", context));
        }
        else
        {
            using (var db = new DB.Context())
            {
                var exec = await db.Builds_GetExecutionAsync(context.ExecutionId);

                await db.Variables_CreateOrUpdatePackageVariableAsync(
                    Build_Id: exec.Build_Id,
                    Variable_Name: VariableName,
                    ValueType_Code: Domains.VariableValueType.Scalar,
                    Variable_Value: InedoLib.UTF8Encoding.GetBytes(commitHash),
                    Sensitive_Indicator: false,
                    EvaluateVariables_Indicator: false
                );

                Log(new SimpleLogMessage(Inedo.Diagnostics.MessageLevel.Information, $"Assigned commit hash {commitHash} to variable {VariableName}", "Git", "", context));
            }
        }

        //Delete the .git Directory
        repo.Dispose();
        Helpers.DirectoryHelper.DeleteReadOnlyDirectory(path);
        Helpers.DirectoryHelper.DeleteReadOnlyFile(context.ResolvePath(".gitignore"));
        Log(new SimpleLogMessage(Inedo.Diagnostics.MessageLevel.Debug, "Removed .git directory and .gitignore", "Git", "", context));              
    }

However, I'm guessing this was written a while ago before the built-in Git operations handled this? We use the Git operations to perform this same functionality by combining two operations:

# Gets source from the BuildMaster repository and creates a release package variable named GitCommit
Git::Git-GetSource
(
    Credentials: GitLab,
    RepositoryUrl: https://gitlab.com/inedo/BuildMaster.git,
    DiskPath: ~\Src,
    RecurseSubmodules: true,
    Branch: $Branch,
    CommitHash => $commit
);

Set-ReleaseVariable GitCommit
(
    Value: $commit,
    Package: $PackageNumber
);

For completeness, after the registry value is configured the server will likely need a reboot to take effect.

Are you able to post the full code, or submit the code as a support ticket if you don't want it public? There must be something else happening because that should definitely work.

See this post:

https://inedo.com/support/questions/8831#inline-post-8848

If you are connecting from a VM that isn't joined to the domain, you need to install the latest Inedo Core extension (i.e. at least v1.0.6) from the Admin > Extensions page (the extension was shipped after the ProGet release).

You would also have to point it at the AD server via Admin > Change User Directory (LDAP) > Advanced > edit "Active Directory (New)", and set the LDAP host or IP there. You can perform most search tests / diagnostics there.

What that article says is that programs should not set specific TLS versions (which ProGet does not) because the defaults will change as the OS is patched/updated. This means that it should be using the most secure by default, which based on the TCP error, it is not doing. Unfortunately this is symptom of applications targeting versions of the .NET Framework before v4.7 like ProGet does (it targets v4.5.2).

We may be able to hack in a fix like we did for our Git extension in a future version, but if you want to get it working right away, follow this part of the guide: Configuring security via the Windows Registry

This is OS & .NET Framework dependent, does this guide help?

https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls

Can you try executing Hedgehog.Service.exe from the command line? Also, can you verify that %PROGRAMDATA%\Inedo\SharedConfig\Hedgehog.config exists and has a valid connection string in it?

I can't seem to find any indication that endpoint is part of official NuGet API, but in ProGet if you want a specific file you can query as per this example:

http://proget.company.com/package-files/download?packageId={packageId}&version={packageVersion}&feedName={feedName}&path={packageId}.nuspec

A live example:

https://proget.inedo.com/package-files/download?packageId=InedoLib&version=528.0.0&feedName=ExternalBuild&path=InedoLib.nuspec

We added basic support for this in BM-3197, though anything more complicated needs to be handled with a custom event listener.

If you want to create a custom extension for this (and are an enterprise customer) you already have access to the source code at https://my.inedo.com, or you can request direct source access to our GitLab repository as well, just send a note via the contact form.

Now that the current version of Visual Studio seems to respect authentication challenges, we are adding support for this. The tracking issue is here: PG-1273

This exact feature was added in v6.0; in that version there is another checkbox when editing the resource credential to "Restrict by environment" and it behaves exactly as you describe.

As a side note, the Agents.EnforceServerRestrictions setting is designed to catch server/environment mismatches (i.e. error out when deploying to stage associated with Integration and targeting a server associated with Production) when deploying and will not affect credentials.

Hello Philippe,

For restartTimeLimit, I believe StartupTimeLimit and ShutdownTimeLimit (in the Process Model tab for the visual editor) are what you're looking for.

I've submitted a pull request to add PeriodicRestartSchedule: https://github.com/Inedo/inedox-windows/pull/35

The latest version was incorrect in the Den -- the latest cross-product TeamCity extension should be v1.0.0, and its legacy counterpart extension (i.e. TeamCityLegacy) should be v6.0.0.

If it doesn't appear on the extensions page in BuildMaster, you can download and install it manually from here: https://inedo.com/den/inedox/teamcity

If you go the manual route, note in the manual installation instructions it says the file extension is ".inedox", while in this case it is actually ".upack". Make sure there is no TeamCity.bmx or TeamCity.inedox in the extension path (TeamCityLegacy.bmx is OK if not a fresh installation of BuildMaster).

Hi David,

This was fixed as part of PG-1096 in v4.8.3

Thank you for the followup, that is good information.

For future reference, the docs for switching from the built-in webserver to IIS can be found here: https://inedo.com/support/kb/1013/hosting-through-iis-instead-of-the-integrated-web-server

The only thing I notice from the article is the mention of Classic mode for the application pool - at some point each product was updated to support Integrated mode.

Yes, here is the tracking issue: BM-3165

It was generalized to use ProGet's API keys which have more granular security options: https://inedo.com/support/documentation/proget/feeds/nuget#nuget-api-key

I think you are a looking for a different vendor - Inedo's BuildMaster is a DevOps tool, not accounting software.