This repository has been archived by the owner on Mar 27, 2024. It is now read-only.
buffalo test -m Test commands fail when using sqlite3 databases #180
Assignees
Labels
bug
Something isn't working
Comments
mattbnz
referenced
this issue
in mattbnz/meta
Jun 30, 2022
When called from within a subdirectory of the app (e.g. from within the processing of buffalo test -m TestName) we need to strip an extra directory off to be able to find the configs, etc. Failing to do this results in errors like sqlite buildtags not being applied correctly. Fixes gobuffalo/buffalo#2284
|
The above commit is an example of how I've been able to fix this locally - but no idea if that's something you'd consider for upstreaming? |
|
checking... (my reproducing attempt shows some different behavior and also some other issues were found, so it could need more time) |
|
Hi! Thanks! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Description
Attempting to run an individual test case against a project using an sqlite3 database fails because of what I think is buggy path handling logic in the meta package... but I'm not entirely sure if it's intended to be able to call that package from a subdirectory of the app.... so filing this here at the top-level...
When using test -m, mFlagRunner changes into the module directory before calling newTestCmd, which calls into meta.New to try and find the app config. Unfortunately when called from with a module directory (not the base app directory) the path handling logic in meta.New generates a bad path for buffalo-config.toml and fails to find it, falling back instead ot the "oldSchool" method which also looks in the wrong place for .buffalo.dev.yaml - with neither of them finding a config file, the build tags are not found, and therefore not passed along to the go test invocation, and the test methods subsequently run without sqlite support :(
I don't know if it's important for the test command to change the working directory before calling newTestCmd? if not, re-ordering that would be an easy fix... although probably the logic in the meta package needs to be made more robust about working regardless of where it's called from.
Separately, along the way I noticed that the sqlite build tag never makes its way into the 'oldSchool' config file, so even if that fallback path was found with the new config wasn't, there's a missing link.... not sure if this is still important to anything else, but may be a contributor to issues like gobuffalo/buffalo#465 even for brand new projects.
Finally, I realise this is an issue in the stable release, and may be fixed in the development branches... but they're so different and divergent in their codebases, that I struggled to find out, and its' significant enough that I think it warrants a fix in the stable branch anyway, hence this bug.
Cheers
Steps to Reproduce the Problem
Expected Behavior
The test will fail anyway, as it's unimplemented, but in the console output you should see go test being called with -tags sqlite, and there should not be any errors from pop.
Actual Behavior
Info
The text was updated successfully, but these errors were encountered: