What is the motivation? I had it like this originally before I moved the logic into the Mekefile but then it seemed to complicated for me.

In particular how is this going to work like that, the makefile uses go test $(BUILDFLAGS) $(TESTFLAGS) -cover ./... so would it not always pass -cover ./... afterwards. Is that even a valid go command then?

Great point about the ./..., thanks! (The way this seems to work is that it does restrict the tests to ./storage, but then it interprets the -cover ./... as options to be passed to the test, and I guess ignored.) I’ll rework this.

(Originally this started as a hack for other reasons), but ultimately it’s a bit unclean, and a bit of a waste, that we test+compile all of those sub packages where we know the filter will not match anything.

(Originally this started as a hack for other reasons), but ultimately it’s a bit unclean, and a bit of a waste, that we test+compile all of those sub packages where we know the filter will not match anything.

Yeah fair enough, if the compile time is noticeable then this seems like an easy win indeed. And I guess the reduced log spam is also nice

Great point about the ./..., thanks! (The way this seems to work is that it does restrict the tests to ./storage, but then it interprets the -cover ./... as options to be passed to the test, and I guess ignored.) I’ll rework this.

At the point of making it even more complicated I think the best thing would be to add yet another variable like TESTPACKAGE which defaults to ./... or something like that and then have the script set it?

if the compile time is noticeable then this seems like an easy win indeed.

I’m not so worried about the compile / run time, with #2837 — if that ever lands. But “conceptually more precise”, “shorter logs” and “probably faster” seems worth doing, even if I started this for all the wrong reasons (to work around an unrelated bug in my work).

For the record, tests are now 6.5–7 minutes, down from 8.5–10 minutes in the previous commit.