Open jkomoros opened 5 years ago
Add to TUTORIAL.md in the "writing your own game" section
It might be simpler to just have golden take a single game import and wire everything up so that you can save new goldens. boardgame-util golden github.com/jkomoros/boardgame/examples/checkers
. That makes the wiring up and cleanup easier to wrap your head around, and in practice you don't want to run multiple games in golden mode anyway.
boardgame-util golden DIR
where DIR can be a package name or a relative path to a game package.
That command first verifies that the given package is a legal game package (moving golden.verifyPkgPath and making a public part of link package). If it passes, and testdata/golden
doesn't yet exist, creates it, and also creates the golden_test.go
.
Then runs build golden PKGNAME
which basically creates a build/filesystem/PKGNAME
that is symlinked to the absolute package directory + testdata/golden
. Then calls boardgame-util serve
but with an override specific gamename only, and --storage=filesystem. The teardown for boardgame-serve naturally cleans up the golden folder structure.
build golden PKGNAME
, which is the build logic just implementedclean golden
which removes the central golden symlink folder, and the test file, BUT ONLY IF THERE ARE NO RECORDS (unless --force) is passed.boardgame-util golden
which basically does a boardgame build golden then boardgame-serve There's a fair bit more behavior to add to the lib/path
library. Could want to 1) Take a string and decide if it's a relative path to a game source dir, or a go import, 2) Get an absolute path to the given go library, 3) decide if it's likely to be a game package path (that is, have NewDelegate with right signature), 4) tell if it's a readOnly location or can be modified. 5) Tell if it has other files like a sub-folder structure of a given shape, the existence of files like golden_test.go
, etc.
The easiest way to do this is to have a new struct called GameImport that abstracts away all of this knowledge. lib/path
then becomes way more powerful, and becomes more like lib/gameimport
.
--ofline-dev-mode
Filesystem should only store in multiple named folders by game type if there's more than one game manager. (Ideally this behavior can be enabled or disabled). Because with golden, it only runs for one thing at a time, and it's way easier if we can just tell it to store in a single folder, and not have to create all kinds of additional faux folder structure. Actually wait--if given a folder there is a subfolder with the gametype's name it will save in there and look in there first. But if not, will just store in the given folde.r That way there isn't multiple options to pass,.
Golden files should be stored in testdata/golden
so as to not conflict with other testdata
Consider renaming the tool to boardgame-util create-goldens
to make it more clear that it's a very rare tool
boardgame-util golden
Originally captured in #655.
Add
bu build golden
andbu clean golden
An alias for
bu build golden, bu serve --storage=filesystem --clean-up, bu cleanup golden
Basically a mode where we wire up and allow serving goldens
Remove the golden behavior from filesystem
golden.LinkGoldenFolders should be split into a more generic helper library that can be used for golden folder generation as well as server client-files auto-siymlnking