Hi, How would you like the error code handled? Would you like the option to store it in a variable, be used to determine success, or just logged somewhere? I believe we can add this by updating the Linux extension. As a workaround, you may be able to use the Exec operation, which already has exit code handling.

That error is coming from the SSH library that BuildMaster uses to connect, and offhand I don't know the causes (aside from obvious). One possibility is that username/password isn't enough, and you need to send a certificate. Putty may already be configured to do this. But can you enable SSH logging on your Linux box? This way, you can see the problems of incoming connections and we can further help from there.

Okay, I've resolved it. The problem was that I'd put in the project name without a path - so BuildMaster was assuming a default path. The message was really unclear. It would be beneficial to allow the user to populate that field with a 'browse' function to find the solution/project or, at the very least, have some validation on the input to ensure you've entered something which looks like a full file path.

I would try reinstalling it. I didn't have to create the site in IIS.

Eric, thank you! That was the issue, I didn't know about that issue.

Typically this is caused by a Windows extension that hasn't been updated to the latest version following a BuildMaster v6 upgrade.

The problem is that OtterScript attempts to parse those variables first. Just use quotes: set $foo = true; set $bar = true; set $foobar = $PSEval("$foo -and $bar"); Log-Information `$foobar = $foobar; # prints: $foobar = True

It does not exist yet, I've filed BM-3326 to add it in v6.1.2

At of ProGet 5.1, that's the only way. We may add support for this in a future version if we get more feature requests

I have had issues in the not too distant past, maybe 3-6 months ago upgrading one of my installs of Otter to the latest version, 2.0.9 if memory servers. I would concur that the installs/upgrades could use some love. There definitely should be a 'cleanup' tool to remove all traces of Inedo installs. Ron, I wouldn't give up on using the products. Maybe you can spin up a vm to try this out on as well?

You can edit the connection string using Inedo Hub; it should be listed right under the Configuration tab. Note you will need to stop/start the service and web app afterwards. Might be best to stop both beforehand, however, so you don't have two potentially active databases.

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

Thanks, I've filed this as a bug here: BM-3307

Thanks for the suggestion, it's handy to know that's possible (with a bit of scripting to move packages into the top level directory). It also seems to work pretty well running the Feed Cleanup under 4.7.14 and then upgrading.

Keep in mind that Timeout (or cancellation in general) is not guaranteed, and requires that the task (generally, an operation) properly check for a cancellation token. For example, an operation that simply did a Thread.Sleep for 1000 seconds could not be timed out after 10 seconds. In a case of a stuck execution, restarting the service is the best way to clear things. So, we'd need more context to identify if it's a bug in the operation, or simply something that isn't support.

The root of the issue is the NuGet team's decision to force SemVer: https://github.com/NuGet/Home/issues/3050

Just as a quick update, this was added to our roadmap as an item we will be including. It'll be implemented likely using the same mechanisms as the Repository Monitors, so it gives a lot more flexibility with regards to what it can do (create builds, create releases, etc), and also uses cron-syntax for scheduling so you have even more flexibility. No ETA, but I've added this post to the project plan so that we will upate it once it gets started.

Just to close this post: this was fixed in InedoCore 1.0.12, after diagnosing the issue on a ticket (EDO-5683).

The SQL server and the application are both on server 'Production' and the application is successfully retrieving data from the SQL server. The connection string used in the application configuration is the same connection string being used in the SQL connection in Buildmaster. It is using a SQL account, so not integrated. Here is a redacted connection string: - Data Source=*************;Initial Catalog=*************;User Id=*************;Password=*************;MultipleActiveResultSets=true;