Consider checking in a static fs hierarchy for tests

[jpo-joyent]

Currently, go test runs against your local machine, and some tests fail depending on what hardware that machine actually has.

It might be a good idea to check in a single fs hierarchy to run tests against (using GHW_CHROOT), and could also serve as a handy reference of file formats for contributors without access to various hardware.

[jaypipes]

I think this is an excellent idea, @jpo-joyent. I'll try to modify our test setup accordingly and make use of the GHW_CHROOT functionality to place a temporary filesystem down for the tests to use.

[ffromani]

Hi there! I'd love to contribute because I'm interested in testing the syfs reading portion of pkg/cpu, pkg/memory and few others.
Few questions (been doing similar things in the past)

• should the testing fs hierarchy be static (e.g. subtree somewhere under test you just check in the source tree)?
• same as above, but maybe with some .tgz file we uncompress on the fly to run tests?
• should the testing fs hierarchy generated programmatically, so it does exist only when test runs?

[jaypipes]

Hi @fromanirh! Check out the ghw-snapshot tool:

https://github.com/jaypipes/ghw/blob/master/cmd/ghw-snapshot/main.go

You can run it like so:

go run ./cmd/ghw-snapshot/main.go

After running that, you will see a $OS-$ARCH-$HASHSYSTEMNAME.tar.gz file in the current directory.

You can investigate this snapshot of tmpfs using the hack/run-against-snapshot.sh script:

https://github.com/jaypipes/ghw/blob/master/hack/run-against-snapshot.sh

Of course, I'm very happy to accept any and all contributions that improve the test coverage in ghw, so please don't let this discourage you! :)

[ffromani]

Thanks for the information @jaypipes ! Far from discouraging, this is a great building block!
I'd like to make use of snapshots systematically in the test suite. I'm most interested in the cpu + topology packages, but we can iterate from there.

Do you think a flow like this could be a good direction?

1. file a PR with few snapshots to be used as test data. Example: few cores (laptop), many cores (12-16 from a beefy workstation), any-cores multi-numa (from server box)
2. enhance the testsuite to (optionally?) unpack the snapshots before the start up
3. pass the locations to unit tests (env vars?), so they can chroot into them and be fully independent from the host
4. clean up on exit

I can contribute (and I'd love to) code & snapshots if we decide to go this direction.

[jaypipes]

@fromanirh sounds like a great direction to me! :)

[ffromani]

@jaypipes great! I'll file PRs to implement this direction ASAP, referencing this issue. Thanks!

[jaypipes]

@jaypipes great! I'll file PRs to implement this direction ASAP, referencing this issue. Thanks!

Rock on :) Thank you so much!