Notes on Go, part 6 of ∞

To deal with the idiosyncratic failing test issues from my last go post, I got to do a bunch of stuff with our monorepo and learn a bit more about the Godep tool, and now I know more about why the stuff at the end of this post works.

The solution to my problem was to update the version of sqlmock that I was using. One of the potential issues with monorepos is that if you update a package, you have to update it across the entire monorepo, because of how Go dependencies work. One solution to this problem is to make whoever wants to change versions do all the updates across the repo. Another (less ‘Go’) solution is to have two versions of the dependency in your project. Which is what we did.

It took me a few tries to get everything down in a way that made both Godep and git happy, so here is my recommendation on the order of steps to take.

  1. Checkout your master branch and make sure it is up to date.

  2. Make sure your local Godeps/_workspace is up to date by running the godep restore command. I think this is the one I was having the most trouble with, because ‘restore’ is not what I think I want to do, conceptually. The restore command is (I think) making your local Godep/_workspace match what is in the Godep.json file. So if you’ve messed added ore removed a whole bunch of stuff, and want to start over, the ‘restore’ command is an accurate reflection of what you are doing, but it also works as an ‘update’, which is conceptually what I thought I wanted to do.

  3. Check your git status and make sure you don’t see anything unexpected. In my case, I didn’t expect to see really anything in my status because our Godep folder is checked into git.

  4. If you haven’t already, do a godep get PACKAGE/I/WANT.

  5. Update the import statement(s) in your actual *.go file(s).

  6. To save this into your dependencies, use godep save -r ./.... The -r flag takes care of re-writing any import statements to now point to your Godep/_workspace folder. The ./... makes sure it checks the current folder and all folders inside of it to catch any new imports.

  7. Again, check your git diff. At this point, I expected to see:

– the import changes
– the new package in Godep/_workspace

If it all looks good, commit!

  1. If this update was a breaking version change, now go back and fix your code that it compiles and runs again.

  2. Finish the thing that sent you down this rabbit hole in the first place!

Notes on Go, part 5 of ∞

Problem: We’re working in a Go monorepo. I’ve been writing tests for one package in one service in said monorepo. When I run
godep go test ./directoryofinterest,
I get the following (positive) message:
ok github.com/path/to/my/directoryofinterest 0.019s.

When I run
godep go test ./directoryofinterest -v,
I get several failure messages in the main part of the output, and the last two lines are
FAIL
and
ok github.com/path/to/my/directoryofinterest 0.021.

This is definitely some unexpected behavior.

Working through some of the 11th chapter of The Go Programming Language has surfaced a few idiosyncrasies.

  1. Running go test from the directory where the tests are returns 2 lines, whereas running go test ./directoryofinterest from one directory up returns only one line.

  2. When you get the 2 lines, one is a PASS or FAIL message, and the second is the ok message.

BUT WHYYYY???

Fun fact: it’s because i”m using an old version of Data Dog’s sqlmock.

After updating sqlmock to the current version, I get the expected behavior when running the tests.

Running the go test ./directoryofinterest now returns 1 line when tests pass with the ‘ok’ message. Running the same command with failing tests returns multiple lines with the details of the failure, and the final line contains the FAIL message.