delete experimental object watcher

delete experimental object watcher

initial event stream implementation Documentation too. It's not quite clear enough that callers need to handle resubscribing on any errors reading the stream. It's documented for Subscribe but example usage would be good too.

wip

Support icinga 2.12 acknowledgement, state, statetype field On Debian 11 these fields are floats, not ints (or boolean) for some reason. This patch allows unmarshalling either floats or integers depending on what the icinga API sends us.

link to the new general mailing list because there's so many subscribers... lol

Store last Host check result and time Includes tests and simplified unmarshal test.

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!