Simplify service JSON marshalling We don't need to have a MarshalJSON method just so that it can be created ok. It's clearer to do stuff necessart for object creation at the time of object creation, not way earlier in some unrelated bit of the code. While here simplify the tests to actually test what we're worried about.

store a service's last check result

icinga_test: Don't assign group for random hosts We can test hostgroup assignment in other tests if desired.

icinga_test: Inline permissions response No need for a file on disk; it's only referenced once.

Run a full test on builds.sr.ht for every commit On OpenBSD. Why not?

Test against a fake in-processs icinga server A lot of the testing doesn't really flex what a real icinga2 server does. We can implement a simple fake server with about 250 lines of Go, then we get all the benefits of really quick feedback and no dependency on an icinga2 server (which isn't super easy to set up) for most tests. More complicated tests are still performed against a real server listening on loopback (if available).

Remove unnecessary parseAPIResponse function All this did was wrap the usual standard library JSON decode procedure.

Remove useless loop We always returned something on the first iteration, so just remove it.

panic on unlikely test case We're just in test mode, so it's ok to panic if we reach this highly unlikely scenario when, for example, the testdata file changes or something.

Use default MarshalJSON method There's no point doing so much manual work and testing just to keep fields under a "attrs" key when marshalling to JSON. When creating the object we can just: 1. Marshal the object to JSON 2. Put it all under a "attrs" key. Now it's easier to imagine the mapping of the structs to JSON, since they follow the same rules as everything else in Go.

Keep test data in version control While here also don't log messages in testing unless there's an error.

Catch all HostStates and ServiceStates This is closer to the Icinga spec, anything greater than 2 or 3 is unknown.

Only log on test error No news is good news!

Just panic on unlikely user test error We're just testing, so we don't need super robust error handling code. And if any of those conditions aren't met then we have serious problems anyway.

Revert "Create a new client interface" This reverts commit bd3b8a33c54037e66233db80fd1120eb0b6215f1. It's a bad idea. I'm writing a fake server instead so that we can use the real client code.

Create a new client interface So that testing the client doesn't involve making real HTTP requests.

Correctly return ErrNoMatch when rescheduling a check For some reason the API returns an internal server error status rather than a Not Found status (as in other methods in the API). We can catch the condition when results are empty and return ErrNoMatch.

Marshal using struct tags rather than a custom map I was excluding some struct fields so I thought I'd need to do some custom marshalling . But you don't need to do this as you can use struct tags to optionally exclude things from being put into JSON. Now there's no longer duplicate code between struct tags and keys in a map when marshalling. Handy!

Delete unused testUser var This was used in some old tests but is now unused.

Properly encode spaces in filter expressions This is a bit tricky. url.QueryEscape() encodes spaces in queries as "+", but Icinga2 wants them as "%20". A test case is included because this was kinda tricky to debug.

Correctly return ErrNoMatch The check was incorrect before. The HTTP status on responses is still 200 OK, but with empty results if there are no matches to the filter.

Store acknowledgement status of hosts, services

Actually return permissions grante to the client Before we were just returning an empty response or something non-meaningful

Let users schedule their own checks

Always format generated code While here document what is needed to actually run go generate.