mirror of
https://github.com/hanzoai/volume.git
synced 2026-10-01 00:48:00 +00:00
zeekay
b61441f7d7
A fork of Rancher's local-path-provisioner at v0.0.36. The behaviour is unchanged and deliberately so — a directory on the node a pod lands on is the right thing for a disk. What changes is identity. The provisioner answers to hanzo.ai/volume rather than rancher.io/local-path. That is not branding: two provisioners sharing one name race for the same claims, and a stock k3s carries the upstream one, so a cluster running both would settle our storage by chance. Data lives at /var/lib/hanzo/volume, so reading a Hanzo cluster does not mean learning another vendor's directory. Apache-2.0 as published, unaltered, with Rancher's attribution in NOTICE. The README says what this is not: durability. A volume here dies with its node. That is hanzoai/replicate's question, one layer up, and keeping the two apart is what lets the disk stay this simple.
71 lines
2.6 KiB
Go
71 lines
2.6 KiB
Go
// Package suite contains logic for creating testing suite structs
|
|
// and running the methods on those structs as tests. The most useful
|
|
// piece of this package is that you can create setup/teardown methods
|
|
// on your testing suites, which will run before/after the whole suite
|
|
// or individual tests (depending on which interface(s) you
|
|
// implement).
|
|
//
|
|
// The suite package does not support parallel tests. See [issue 934].
|
|
//
|
|
// A testing suite is usually built by first extending the built-in
|
|
// suite functionality from suite.Suite in testify. Alternatively,
|
|
// you could reproduce that logic on your own if you wanted (you
|
|
// just need to implement the TestingSuite interface from
|
|
// suite/interfaces.go).
|
|
//
|
|
// After that, you can implement any of the interfaces in
|
|
// suite/interfaces.go to add setup/teardown functionality to your
|
|
// suite, and add any methods that start with "Test" to add tests.
|
|
// Methods that do not match any suite interfaces and do not begin
|
|
// with "Test" will not be run by testify, and can safely be used as
|
|
// helper methods.
|
|
//
|
|
// Once you've built your testing suite, you need to run the suite
|
|
// (using suite.Run from testify) inside any function that matches the
|
|
// identity that "go test" is already looking for (i.e.
|
|
// func(*testing.T)).
|
|
//
|
|
// Regular expression to select test suites specified command-line
|
|
// argument "-run". Regular expression to select the methods
|
|
// of test suites specified command-line argument "-m".
|
|
// Suite object has assertion methods.
|
|
//
|
|
// A crude example:
|
|
//
|
|
// // Basic imports
|
|
// import (
|
|
// "testing"
|
|
// "github.com/stretchr/testify/assert"
|
|
// "github.com/stretchr/testify/suite"
|
|
// )
|
|
//
|
|
// // Define the suite, and absorb the built-in basic suite
|
|
// // functionality from testify - including a T() method which
|
|
// // returns the current testing context
|
|
// type ExampleTestSuite struct {
|
|
// suite.Suite
|
|
// VariableThatShouldStartAtFive int
|
|
// }
|
|
//
|
|
// // Make sure that VariableThatShouldStartAtFive is set to five
|
|
// // before each test
|
|
// func (suite *ExampleTestSuite) SetupTest() {
|
|
// suite.VariableThatShouldStartAtFive = 5
|
|
// }
|
|
//
|
|
// // All methods that begin with "Test" are run as tests within a
|
|
// // suite.
|
|
// func (suite *ExampleTestSuite) TestExample() {
|
|
// assert.Equal(suite.T(), 5, suite.VariableThatShouldStartAtFive)
|
|
// suite.Equal(5, suite.VariableThatShouldStartAtFive)
|
|
// }
|
|
//
|
|
// // In order for 'go test' to run this suite, we need to create
|
|
// // a normal test function and pass our suite to suite.Run
|
|
// func TestExampleTestSuite(t *testing.T) {
|
|
// suite.Run(t, new(ExampleTestSuite))
|
|
// }
|
|
//
|
|
// [issue 934]: https://github.com/stretchr/testify/issues/934
|
|
package suite
|