Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generated Mock Importing Non-Existent 'command-line-arguments' Package #744

Open
jcburley opened this issue Jan 6, 2024 · 2 comments
Open

Comments

@jcburley
Copy link

jcburley commented Jan 6, 2024

Mockery sometimes generates bad code (in the form of a package import), but running go clean -modcache and rebuilding seems to have fixed it on my laptop; yet the problem also repeatedly occurs when running our build using Docker in a Jenkins CI. (Perhaps our Golang image isn't starting out with a clean modcache?)

Mockery was generating this code:

// Code generated by mockery v2.39.1. DO NOT EDIT.

package mock_pkg

import (
	paycycle "command-line-arguments"
	context "context"

	mock "github.com/stretchr/testify/mock"
)

In both Docker and, earlier at least, on my laptop, numerous errors were shown regarding "could not import ... (no metadata for ...)", including for the context package in std.

But the following subsequent errors really stand out and suggest something weird is going on in parsing, which might be leading to the command-line-arguments error shown above:

06 Jan 24 10:23 EST ERR Error parsing file error="-: # command-line-arguments\ninternal/pkg/tcpmessages/new.go:4:38: undefined: TCPMessage\ninternal/pkg/tcpmessages/new.go:5:16: undefined: Message\ninternal/pkg/tcpmessages/new.go:10:23: undefined: ErrorMsg\ninternal/pkg/tcpmessages/new.go:21:20: undefined: Message\ninternal/pkg/tcpmessages/new.go:24:18: undefined: MessageType\ninternal/pkg/tcpmessages/new.go:24:49: undefined: Message\ninternal/pkg/tcpmessages/new.go:35:19: undefined: MessageType\ninternal/pkg/tcpmessages/new.go:35:51: undefined: Message\ninternal/pkg/tcpmessages/new.go:46:20: undefined: MessageType\ninternal/pkg/tcpmessages/new.go:46:52: undefined: Message\ninternal/pkg/tcpmessages/new.go:10:23: too many errors" dry-run=false version=v2.39.1

Upgrading to Go 1.21.5 and Mockery 2.39.1 doesn't seem to have resolved these issues. And I can't find any salient occurrences of the string command-line-arguments in our source (including vendor code), in Mockery, or even in the Go source tree.

Is this worth investigating further? golangci-lint does show some vanilla lint issues (no obvious problems parsing the source code), and go test -v ./... actually passes all the tests (there aren't any in the generated mock* directories, of course), so it's not noticing any problems with the source code.

If necessary, I can try to gather all the info on versions and such, but first wanted to see if anyone recognized the above and could recommend a course of action.

In the meantime, I'll at least fix the lint issues to get a clean run, just in case that helps spot some issue.

Thanks, and apologies for the vague/weird Issue lacking (so far) a repro.

@LandonTClipp
Copy link
Contributor

LandonTClipp commented Jan 8, 2024

I think it would be worthwhile for you do post a few things here:

  1. Your .mockery.yaml file (if any)
  2. The logs of mockery using --log-level debug
  3. The details of how the docker container is being built/run, including the presence of any cached packages, and any volumes mounted from the host to your container.

I would recommend clearing your entire Go cache on your Jenkins server. This really smells to me like you have some incompatibility with a cached package and the Go version being used in mockery. In my professional experience when encountering issues like this, this tends to fix it.

@jcburley
Copy link
Author

jcburley commented Jan 9, 2024

Thanks @LandonTClipp — I'll try to get to that soon, as I believe you're correct that our base Golang Docker image might have a corrupt cache, since adding go clean -modcache to our package's Jenkins pipeline, just before building, made the issue disappear, just as happened on my laptop.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants