Posts made by jrasch

@Adam - I have filed https://github.com/Inedo/inedox-windows/issues/70 to update the existing function to support referencing UsernamePassword credentials so you don't need to use $CredentialProperty

Thank you for the report, this is resolved via: PG-1447

This has also been reported in our Jenkins extensions issues section, can you take a moment to respond to the questions I posed here?

https://github.com/Inedo/inedox-jenkins/issues/26#issuecomment-454188149

Thank you for reporting this - we've determined the root cause and will issue a fix for this ASAP.

Apologies - I broke that endpoint earlier ironically by accidentally disabling logging :(

It should work now; I also note that you can request a key at https://my.inedo.com and manually enter it.

Here is a working PowerShell example (v6.1+):

Invoke-RestMethod -Method POST -Uri "http://{bmserver:port}/api/releases/builds/deploy?applicationName=ApiTest&releaseNumber=1.2.3&buildNumber=1&key=<api-key>"

For pre-v6.1 versions, the equivalent is:

Invoke-RestMethod -Method POST -Uri "http://{bmserver:port}/api/releases/packages/deploy?applicationName=ApiTest&releaseNumber=1.2.3&packageNumber=1&key=<api-key>"

I have also put in a doc change request to clarify the endpoint names.

Additional note: -UseDefaultCredentials would be required if Integrated Authentication were enabled.

Hello Attila,

If you run docker inspect proget -f '{{json .Mounts}}', does it include /var/proget/extensions as both the source and destination of one of the bind mounts?

Python and Debian feeds will be officially rolled out with our v5.2 release in March 2019. See the Products Roadmap for more information.

Good idea, I thought we already had the ability to do that, but I was confusing it with Job History.

Here is the associated issue: OT-278

This will be resolved as part of: OT-274

The workaround is to browse to the URL directly, e.g .

http://{otter-host}/executions/logs?executionId={execId}&level=0&download={true/false}

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.

We will implement retention policy filtering by version. See the tracking issue here for updates: PG-1278

Hopefully it will be in the official v5.1 release (or soon-after maintenance release) but it may also be there earlier since we are also going to allow pre-release product versions to be downloaded from the Hub installer.

The fix will be part of that (it was actually a regression in the Pipeline picker control which is on both of those pages).

Thank you for the report, this has been identified as BM-3198 and will be the only issue in the release later today that moves BuildMaster v6 out of beta.

This will be fixed in PG-1273 for the next maintenance release.