I have emailed you the white paper that has a hands-on example for this.

A 2nd server license is required for this:

https://inedo.com/support/documentation/various/licensing/management

Hi Jim,

Apologies for the lack of response here, but I wanted to let you know that we had quite a bit of back-and-forth internally on this post and implemented nearly all of your expectations:

1. you are absolutely correct about the variable context not behaving as expected, and
2. the biggest problem was that the behavior of certain variables (particularly $RoleName) was undefined
3. we've updated the docs to reflect the "new" behavior in the latest version (v2.1.0 at the time of this post): https://inedo.com/support/documentation/otter/core-concepts/jobs#orchestration-job-context
4. we release v2.1.0 last night with these changes included

Thank you again for the detailed report and reproduction steps.

Thank you for the report and additional information; I have filed this as an issue to be fixed in the next maintenance release due out next week: PG-1406

Thanks, I've accepted and released this change in the Windows extension v1.0.10

We consider v2 and v3 to already be semi-retired, which means that we will provide very limited support to users who have not yet upgraded, and will provide assistance in performing upgrades. However, we will no longer ship maintenance releases, patches, or other changes for those versions.

Ahh I see the confusion now. The important bit is that I am using a completely different API (i.e. the Variables Management API that Tod originally mentioned at /api/variables, not the Infrastructure API at /api/infrastructure) to accomplish the same task as a workaround. These endpoints are also far more powerful for variables specifically (i.e. you can edit multiple at once, handle multi-scoping, etc.)

As I mentioned, what you did originally is supposed to work, and there is a bug filed to fix for the next release: https://inedo.myjetbrains.com/youtrack/issue/OT-257

You can adapt it to your method (i.e. just use JSON directly as you did in your previous example), I just already had this script handy and don't like putting the API key in the query string if I can avoid it.

That is indeed a bug in that particular API, but in the meantime the variables API can be used as follows:

$VariableObj = @{
    name = "Viking"
    value = "True"
    server = "hdarsintsv1"	
}

$Headers = @{
    "X-ApiKey" = "blahblah"
}

Invoke-RestMethod "http://otterint/api/variables/scoped/single" -Method Post `
    -Body ($VariableObj | ConvertTo-Json) `
    -Headers $Headers -Verbose

There must be some confusion here (and that is understandable since it's a legacy feature that I am in the process of reworking to support the "provider-less" model).

An SCM Trigger cannot create a release, only a release package. If there are no releases (or the specific selected release doesn't exist) nothing will happen.

Can you share the example pipeline, and the plan associated with its first stage's target?

Thanks for the update; due to its severity we put out an emergency maintenance release to fix this.

Thank you for the report; this is filed as: OT-252

As a workaround, you can assign the server directly to the "Default" raft instead of the "not selected" option.

I had a look at the dump and it seems that the only way this is possible is if installedPackages.json still exists in the %ProgramData%\upack directory.

What is the output if you run: C:\Program Files\Inedo Hub> .\hub.exe list

The quickest is a service like: https://wetransfer.com/

I have confirmed via the installer's source code that the registry values outlined by George, and the %ProgramData%\upack directory Tod mentions are the only places the installer checks to determine if a product is installed. The only other thing I can think of is that there's a key in the WOW6432Node, though I don't find that particularly likely.

If there are no logs from the installer, the only other way we could debug this is via a memory dump. When running the Inedo Hub, right-click on it in the Task manager and choose "Create dump file", then we can investigate further.

BuildMaster does all of these things, it's almost as if you've rewritten the feature page for it in bullet form :)

Most downloaders start by getting a super simple app deployed and then expand on it. Here is the "starter" tutorial we recommend (it should hopefully make sense even if you don't use .NET or IIS):

https://inedo.com/support/tutorials/buildmaster/deployments/deploying-a-simple-web-app-to-iis

The tracking issue for this is here: PG-1309

This is a result of the bug described here: PG-1308

As an aside, if you received a "site cannot be started" error from IIS, see:

https://stackoverflow.com/questions/31487313/website-cannot-be-started-another-website-may-be-using-the-same-port/49638514#49638514

Is this what you're looking for?

set $SitesJson = >>[
    {
        "Name": "Site11", 
        "Bindings": [{
            "IPAddress": "*",
            "Port": 80,
            "HostName": "*",
            "Protocol": "http"
        }]
    },
    {
        "Name": "Site12", 
        "Bindings": [{
            "IPAddress": "192.0.2.0",
            "Port": 81,
            "HostName": "site12.local",
            "Protocol": "http"
        }]
    }
]>>;

foreach %Site in @FromJson($SitesJson)
{
    set $SiteName = %Site.Name;

    IIS::Ensure-Site $SiteName
    (
        Path: C:\tmp\$SiteName,
        Bindings: %Site.Bindings
    );
}

Note the JSON string can come from anywhere (e.g. can be saved in an Asset and pulled then read with Get-Asset tmp.json and $FileContents(tmp.json)).

Also if you want, you can skip the JSON altogether and just set a map from the start:

set @Sites = @(
    %(
        Name: Site11,
        Bindings: @(
            %(
                IPAddress: *,
                Port: 80,
                HostName: *,
                Protocol: http
            )
        )
    ),
    %(
        Name: Site12,
        Bindings: @(
            %(
                IPAddress: 192.0.2.0,
                Port: 81,
                HostName: site12.local,
                Protocol: http
            )
        )
    )
);

Though it's probably easier to read the JSON, so that's just personal preference.