go-template
go-template copied to clipboard
feat(logging): Swap loggers from zap to log/slog
This PR replaces go-uber/zap
with Go standard library's log/slog
. The internal/log
package within the template folder now includes:
- a
New(level string) *slog.Logger
function to replace the formerNewAtLevel
function. It still works pretty much the same way but does not return an error through safe defaults. - a
NewSpanContextHandler(handler slog.Handler, withSpanID bool) slog.Handler
function, that decorates aslog.Handler
to add context-provided trace and span IDs as attributes (optional) - a
InterceptorLogger(l *slog.Logger) logging.Logger
function which could be used for gRPC services as a logging interceptor.
When adding the span context handler and interceptor logger logic, the tests started failing with an error:
--- FAIL: TestGT_InitNewProject (0.05s)
--- FAIL: TestGT_InitNewProject/generates_folder_in_target_dir_and_initializes_it_with_go.mod_and_.git (0.01s)
new_test.go:505:
Error Trace: /Users/pinto_ramos_/mygo/github.com/SchwarzIT/go-template/pkg/gotemplate/new_test.go:505
Error: Received unexpected error:
template: :25: function "Name" not defined
Test: TestGT_InitNewProject/generates_folder_in_target_dir_and_initializes_it_with_go.mod_and_.git
After some debugging this error was coming from the text template parser, as it read through the test files, found two open braces and thought it should be handling a template. To address this issue, I've changed pkg/gotemplate
not to parse the content with the text template if it is a *_test.go
file. This approach can be discussed better in case we'd prefer to have an exclusion list for specific paths, instead.
Closes #311
Hi @zalgonoise, I see that you wrote all test cases manually for the logger. Go provides slogtest
, which tests every function of a slog handler. We could use this :)
It checks that all keys and values are printed, that the groups work, and stuff like that.
I also edited the title to fit the conventional commits convention, as we usually use it:
We can discuss getting rid of it, and use GitHub labels instead. This would also make the releases prettier with GitHubs changelog generator.
PS: The issue number / reference is automatically added when we squash the PR.
Hi @zalgonoise, I see that you wrote all test cases manually for the logger. Go provides
slogtest
, which tests every function of a slog handler. We could use this :)It checks that all keys and values are printed, that the groups work, and stuff like that.
Hi @MarvinJWendt :D I also looked into slogtest
, at least when adding the span context middleware, but the reason why I scratched it for some simpler, more straight-forward tests, was because this package seems to be more prepared to test the actual slog.Handler implementations in the context of writing logs to an output.
So, when using the interface as middleware, it felt a bit like I was just testing the standard library's JSON slog.Handler just to look for an attribute! But give me some time to read through the package a bit more, if I can find a good way to use it without checking the other attributes :)
I just found this one minor simplification. Nice job!
@johannes-riecken awesome input! Thanks for noticing, I don't know how I let that slide! :D
Looking into this (and other) PR's CI jobs, it seems that the semgrep one is failing:
Prepare workflow directory
Prepare all required actions
Getting action download info
Error: Unable to resolve action `returntocorp/semgrep-action@v1`, unable to find version `v1`
Looking into semgrep's action on Github, it seems that they've marked it as deprecated. They point to the following guide for Github
The problem that I am having is their requirement to login in order to have the Sarif output that is used for github/codeql-action/upload-sarif
. I tried running the semgrep container locally with:
docker run -it -v "${PWD}:/src" returntocorp/semgrep:latest semgrep ci --config 'p/auto'
The command above runs fine (and we can include it in the Makefile as well). However if I add the --sarif
flag, it asks to login first. I guess that this is where the Github token comes in, in their guide.
docker run -it -v "${PWD}:/src" returntocorp/semgrep:latest semgrep ci --sarif
run `semgrep login` before using `semgrep ci` or set `--config`
Does anyone have a better idea on how we should approach this change, for semgrep? :)
@MarvinJWendt another update regarding slogtest
:D
Unfortunately, we are unable to use it for this particular wrapper / decorator. The problem with slogtest
is that it has zero tests using context!!
While that makes it a great suggestion for the experimental repo, we need that context for those tests. A regular (*slog.Logger).Info
call uses a context.Background()
when it hits the Handle
call in the slog.Handler
:)
Waiting for #328, to run CI workflows again
I noticed that I left an unresolved comment, it's already as an accepted change :D @johannes-riecken would you like to take another look? :)
resolved conflicts on go.mod / go.sum :)
while we're at it, updated all dependencies (within Go 1.21). We're still able to do the jump to 1.22 at any time :D probably in a dedicated issue / PR
GOMAXPROCS seems to be using logfmt. Can we make it use our logger? 🤔