logging: allow to provide custom core factory func

[yhabteab]

It's kinda annoying that the tests spams the GHA logs with lots of log messages even though the tests aren't failing, see ¹ as an example. Since zap already provides a logger that logs to the testing.T instance, allow overriding the core factory to use that logger instead. This way, the logs are only visible when the test fails or when running the tests with the -v flag.

Tests

~/Workspace/go/icinga-go-library (logging-with-factory ✗) go test './logging/...'
ok  	github.com/icinga/icinga-go-library/logging	0.212s
~/Workspace/go/icinga-go-library (logging-with-factory ✗) go test -v './logging/...'
...
=== RUN   TestNewLoggingWithFactory
=== PAUSE TestNewLoggingWithFactory
=== CONT  TestNewLoggingWithFactory
    logger.go:146: 2025-09-04T17:38:01.177+0200	DEBUG	my-component	This is a debug message
    logger.go:146: 2025-09-04T17:38:01.177+0200	INFO	my-component	This is an info message
    logger.go:146: 2025-09-04T17:38:01.177+0200	DEBUG	my-component.child	This is a debug message from child
--- PASS: TestNewLoggingWithFactory (0.00s)
PASS
ok  	github.com/icinga/icinga-go-library/logging	0.249s

Footnotes

1. https://github.com/Icinga/icinga-notifications/actions/runs/17466069738/job/49602019404?pr=270 ↩

[yhabteab]

Oh, the tests on GitHub are of course run with the -v flag, this will only be relevant when running the tests locally.

[oxzi]

Oh, the tests on GitHub are of course run with the -v flag, this will only be relevant when running the tests locally.

I am unsure, but wouldn't just dropping -v do the trick?

[oxzi]

There is no reason to reorder the imports.

Most (or all?) Icinga Go code just uses one big import block. While I personally dislike this pattern and would prefer grouped imports, it should at least be consistent.

[yhabteab]

I'm not going over all the files now and group some random imports, I didn't even do this change by hand. Each time I edit a go file Goland do this automatically and I've to literally play cat and mouse with it, so that I can commit other relevant changes without this, but it's too annoying, so I gave up. And no, I'm not using any special IDE flags to enforce that grouping, like I said last time, it just seem to happen since the last upgrade.

As you can see, it just uses the simple goimports command without the Group packages from Go SDK option set, so 🤷‍♂️!

[lippserd]

Don't use goimports but gofmt. Maybe this is new?

[yhabteab]

Hm maybe, looking at the goimports command source code, its format-only option says this:

if true, don't fix imports and only format. In this mode, goimports is effectively gofmt, with the addition that imports are grouped into sections.

[yhabteab]

Oh, the tests on GitHub are of course run with the -v flag, this will only be relevant when running the tests locally.

I am unsure, but wouldn't just dropping -v do the trick?

The trick? Dropping the -v flag will only hide outputs written into the testing.T instance, and we use just regular console loggers, so this PR is supposed to allow just this. With this PR, the unittests can use a zaptest logger which forwards everything to the provided testing.T instance, and so the output can be controlled with the -v flag just like regular test outputs.

[yhabteab]

Oh, the tests on GitHub are of course run with the -v flag, this will only be relevant when running the tests locally.

I am unsure, but wouldn't just dropping -v do the trick?

The trick? Dropping the -v flag will only hide outputs written into the testing.T instance, and we use just regular console loggers, so this PR is supposed to allow just this. With this PR, the unittests can use a zaptest logger which forwards everything to the provided testing.T instance, and so the output can be controlled with the -v flag just like regular test outputs.

Ok, I'm noticing now that the existing incident tests do indeed use a zaptest logger, the problem was just due to a not yet pushed code of mine, which just uses a regular console logger. Nonetheless, it would be nice to have this helper function as it allows to construct a test Logging instance, which is required by the config.NewRuntimeConfig function in Icinga Notifications.