How to run go generate before the action?

[golangci]

How to run go generate before the action?

[steebchen]

Yeah, if I recall correctly, I think that worked – but as I said above, you get bombarded with those error messages. And if you have a lot of dependencies it will spam your logs. I've see a few tens of thousands of lines just filled with those errors since it logs one line per file. So something is wrong with the cache restoration, even though it works in general. Which makes sense, since it probably doesn't expect something modified when restoring the cache. So I would personally classify this more as a bug report or feature request to make go generator work without running into this stream of errors and making the cache restoration work.

[steebchen]

You can use the repo https://github.com/prisma/prisma-client-go. I'm currently using the raw golangci-lint binary instead of this action and use the github cache action myself.

However, I have created steebchen/prisma-client-go#276 to re-create the error; you should be able to inspect the logs from the action there. You can see that the latest test run logs are spammed with error logs since the log restoration didn't work.

It's maybe not the best repo to create a reproduction since it does quite a lot of things. In theory any repo which changes the code on go generate should reproduce the error.

[torbjornvatn]

@sayboras I get the same type of error when I try to use actions/cache before the linting action, so does this guy #135
I took at stab at fixing this by adding a disable-caching parameter over in my fork here, but it didn't work. To me it looks like it's the calls that this action makes to setup-go that causes the /bin/tar errors, but I couldn't really figure out what it was.

[sayboras]

@steebchen without going much to details, but I think you can just simply run go generate as part of github action job before running golangci-lint-action. If I am not wrong, golangci-lint expects the compilable codebase to execute properly.

[sayboras]

I've see a few tens of thousands of lines just filled with those errors since it logs one line per file

So I would personally classify this more as a bug report or feature request to make go generator work without running into this stream of errors and making the cache restoration work.

I still feel this is the result of un-compilable codebase, but not the issue with caching or golangci-lint. Maybe related to golangci/golangci-lint#1043 🤔

Personally, I follow alternative approach, which checks in generated file and verifies in github action with go generate again + git diff --exit-code. One benefit is that codebase is compilable right after clone. It's just style thingy I think.

[steebchen]

I still feel this is the result of un-compilable codebase

I'm not sure if I follow. Everything works as intended, the code complies (after go generate is run) and it properly detects errors and fails if there are any, just the cache restoration does not work and results in these errors.

I do need to run go generate on each checkout since I don't commit generated code into VCS, but I think that's a perfectly valid workflow.

[sayboras]

hi, what I mean is just fresh clone + go build directly. Thinking about this, I feel like I might have pre-mature assumption, sorry about this. Let me try with your repo some time this week to understand the flow properly 🤔

PS: Seem like the original error messages might not have repo name, can you share or confirm if it's public repo ?

[andig]

Would be great to fix the /bin/tar errors. Even if they don't hurt the functionality it makes finding the actual lint output in the GHA ui hard.

[bailejl]

I had the same error using Bazel to generate protobufs. By moving this generation work to another job in the same action file and making golangci-lint job dependent on it with the needs tag, I was able to get around the issue. Hope this helps someone.

[steebchen]

yeah I guess this is a duplicate of #81 #135, except that the other issue describes the actual problem more clearly

[andig]

This is #81?

[steebchen]

whoops, thanks. I meant #135

[ldez]

duplicated of #135