When trying to access the API to create a build, a release and deploy, you receive a number of errors that don't meet the specification:

Ok, lets start by getting the releases of all the applications

Invoke-WebRequest -Uri "http://localhost:8622/api/releases?key=test" -Method Get

#Invoke-WebRequest : Object reference not set to an instance of an object.
#At line:1 char:1
#+ Invoke-WebRequest -Uri http://localhost:8622/api/releases?key=test -M ...
#+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
#    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Never mind, that didn't work, so instead lets go ahead and create a release against application ID by sending that in the POST body

Invoke-WebRequest -Uri "http://localhost:8622/api/releases/create?key=test" -Method POST -Body (@{ "applicationId" = 1 } | ConvertTo-Json)
#Invoke-WebRequest : An application name or ID is required.
#At line:11 char:1
#+ Invoke-WebRequest -Uri http://localhost:8622/api/releases/create?key= ...
#+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
#    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Oh, that didn't work. Never mind, let's send it via Params instead!

Invoke-WebRequest -Uri "http://localhost:8622/api/releases/create?applicationId=1&key=test" -Method POST
#Invoke-WebRequest : A pipeline name or ID is required.
#At line:19 char:1
#+ Invoke-WebRequest -Uri "http://localhost:8622/api/releases/create?app ...
#+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
#    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Ah I forgot the pipeline ID, so that's add that in. Only I don't have the ID because GET doesn't work so lets instead use the name

Invoke-WebRequest -Uri "http://localhost:8622/api/releases/create?applicationId=1&pipeLineName=Default%3A%3Atest%3A%3APipeline%3A%3ARelease&key=test" -Method POST
#StatusCode        : 200
#StatusDescription : OK
#Content           : {"id":1,"number":"0.0.0","name":"0.0.0","sequence":1,"status":"active","createdBy":"API","createdOn":"2024-02-02T19:34:11.5330000Z","applicationId":1
#                    ,"applicationName":"test","pipelineName":"Default::...
#RawContent        : HTTP/1.1 200 OK
#{"id":1,"number":"0.0.0","name":"0.0.0","sequence"...

nice that worked! So lets create a build in that release

Invoke-WebRequest -Uri "http://localhost:8622/api/releases/builds/create?applicationId=1&releaseId=1&key=test" -METHOD POST
#StatusCode        : 200
#StatusDescription : OK
#Content           : {"id":1,"number":"1","status":"active","createdBy":"API","createdOn":"2024-02-02T19:35:59.5570000Z","applicationId":1,"applicationName":"test","pipel
#                    ineName":"Default::test::Pipeline::Release","releas...

Nice that worked too. We are getting somewhere here. Lets try and go and see that build in the web GUI so we can check progress before doing a deployment

Uh oh..........

Ok, lets try and create another build manually instead

When a Otter monitored server loses contact with the server hosting the Otter service (because of network problems), during a job run, the job runs indefinitely and will never cancel without manual intervention.

On Otter webpage, It will show the server as remediating the drift, but the status text will never update. Logging on to the server will show a Otter service running and associated PowerShell spawned script processes.

On one server it told me it had started on 19/01/2024 but had only run for 19:23 hours/mins. The job run time does not appear to have dealt with more than one day.

There appears to be a problem with Otter that once it has sent a command to the server needing remediating, it fails to check on the status of it running's and instead needs to force a cancel out if it loses contact. This callback home method would ensure that if connection from the remediating server to the host server has been lost for a long time (1 hour?) any scripts are cancelled. When connectivity is re-established, the run should be updated to show a failure and the server return to an "Error" state rather than "Remediating drift"

I have asked this before but was told to wrap my commands in a "maximum time" loop (which didn't work) and also that it was a result of user interaction being requested. However across over 50 servers I've seen them recently fail on 7 different tasks at different times. None of the scripts have any user interaction in, and when there is no infrastructure problems, they all run perfectly!

I fix this issue by restarting the Otter service via the Web App which clears the outstanding jobs. This isn't however very ideal! I have thought about writing a scheduled task to do this daily but it seems a bit of a fudge!

Can we look at this issue again because it's problem the only thing about Otter that makes it unattractive to other users when I tell them about it.

I use Otter and BuildMaster together. Otter shares its configuration data with Buildmaster with Otter being the SSOT (single source of truth) and BuildMaster reading only.

I create Roles on Otter for builds that I want to deploy to servers (for instance "Pre-Deployment Servers"). I then add servers to these roles. However, the server will be a member of multiple different roles. For instance it may also be a member of "Patching Thursday" server role. The servers are set to detect and remediate drift immediately.

BuildMaster uses the Pre-Deployment Servers role to deploy a pipeline to. This works very nicely but unfortunately because the servers in the Pre-Deployment Servers have no configuration (the job of the role is just to group servers), when I look on Otter, they constantly look like they are in an "unknown" state because no drift can be detected on the Pre-Deployment role even though the Patching Thursday server role is showing green.

I've tried all sorts of things to try and make them turn Green including on the Pre-Deployment Servers role changing the desired configuration to:

1. Adding a simple PowerShell script with return $true
2. Adding an empty configuration file.
3. Getting it to perform stupid tasks (get the computer name).

Is there anything I can do to fix this?

When you create a new install of Buildmaster (2023.9) it is possible to enter a circular loop with service install if the user installing the application has privileges to SQL but the default service logon user does not.

Steps to reproduce:

1. Install the application using a user which has administrative privileges on the SQL box which by default sets the service to use the NT AUTHORITY\Network Service (default option) privilege.
2. Ensure this user does NOT have access to SQL.
3. Watch the services go in a circular starting state (Buildmaster Web Service and Buildmaster Service).

You can only diaganose this error by examining the event logs which displays the SQL login error. To fix this, you need to add the Network Service user to the SQL box or change the logon user for the services.

This is not good behaviour for Windows Services which already have built in error detection and handling.

Expected behaviour: service fails to start up and gracefully shuts down. Records entry in log.

When adding a new Otter server using the API, it is possible to omit an environment.

The API call is successful and the server is created. When this server is assigned to a role, which has the option set to "detect and remediate drift immediately", the server's state will stay in "detecting configuration drift" instead of erroring out. It will stay in this stay indefinitely.

Steps to reproduce:

1. Create a new server via API with hostname, IP and roles but no environment.
2. Set the server to remediate immediately.
3. Check on the server's status. It will say "detecting configuration drift" indefinitely.

Expected response:

1. No environment set OR
2. Environment not needed to run drift detection

When trying to perform a GET on Buildmaster (latest version) http://localhost:8622/api/releases?key=test, you receive an error stating"Object reference not set to an instance of an object."

Steps to reproduce:

1. Create a new API key.
2. Try a GET request against /api/releases with the key specified (as per https://docs.inedo.com/docs/buildmaster-reference-api-release-and-build)

Expected response: A list of releases
Actual response: Object reference not set to an instance of an object

Also if you try to enter an invalid key as AES no validation appears and it won't just save. Appears maybe the validation has fullen off this?

SSL is not affected by this - I can choose SSL fine.

Thanks Alana, can you take another look at this bug
I've just done a clean install on a server and can re-produce.

1. Add a server using an encryption key.
2. Agent goes into "Error" mode

3. Click on error.
4. Shows needs an AES key.

5. Go to server.
6. Click edit and type in AES key.

7. Save.
   8 Go back into server. AES key has gone

@Dan_Woolf Thank you I've now produced a dashboard using this API to show my GREEN/RED status without requiring a login. I know its a lot to ask but adding dashboards public would be amazing in Otter. My code is only about 6 lines but not sure how much effort this is to add into Otter.

I've just upgraded to Otter .14 and found that a number of features have stopped working. Has anything changed?

I can no longer delete a server - I get a 500 error after a long time which message "timeout".
I can no longer edit an AES encryption key of a server, when I save the changes the encryption method goes to "None" and can't be changed back.

This all started when I noticed a number of agents that were working perfectly before the upgrade have started dropping of. These are across a range of environments and all of them I have tried:

1. Restarting the agent
2. Restarting the server
3. Restarting Otter service.
4. Restarting Otter infrastructure job runners (under Admin)
5. Restarting server hosting Otter.
6. Installing new agent version (51 - we were on 50).
7. Checked firewall settings.

I got to point 7 - and then though I'd change the encryption settings to see if that would fix the agents which highlighted these two bugs. The original error is that Otter is now showing "Agent Error" for a number of devices. These are all Windows devices using Agent.

Another small bug is that renaming a role or deleting a role tries to redirect you back to the old named page result in a 500.