This potentially replaces #32, #21, #48, #20, #46, #33, #34, #35, #36,#29, #51
Also #25, #36 would need upates to remove "build" language, and just keep "test".
There may be other tickets this eliminates, but those are all I saw for now.
Story
As devs, we should have a stubbed CI flow for each part of the project, so we can easily plug in various tests to the CI once we have them running.
Acceptance Criteria
test functions stubbed for all parts of proj
build.py test mobile runs mobile test stubs
build.py test ml runs ML test stubs
build.py test api runs ML test stubs
build.py test runs all tests
build.py test output should be human-readable when run locally
build.py test output should be machine-readable when run by CI
Pushing to our personal branch should result in Travis calling build.py test
We can open a PR from our branch to master any time, but the PR cannot be merged into master until test_all() passes on Travis
Explicit override to merge a PR even when tests don't pass should be possible, in case Travis is having issues. I think Github provides an override option by default, so likely nothing to do on this one other than check that the override exists.
As we understand the project parts better, we should be able to replace stubbed functions with appropriate calls to test the project's different parts (.e.g, expo test for mobile)
PipEnv to manage dependencies
Depends on:
travis config permissions (can get from Adam)
github repo settings config permissions (let adam know what you need)
57
Relates to:
Slack message:
@everyone Another potential way to simplify. The more we learn about the different project parts, the more I'm realizing that there are some huge differences between a conventional web project and this. For example, a mobile build (i.e., compile) process might produce a packaged app that's publishable to the android/apple stores - something we're unlikely to need (AFAIK). Since we aren't actually publishing distributions, and python doesn't need compiling, I think we can potentially skip compile steps for all parts of the project entirely. Not 100% sure though. Any reasons y'all can think of to have a compile step?
Github flow diagram (though the order is slightly different):
A few things I didn't fully implement on this ticket because they were not possible with my account, or impractical:
We can open a PR from our branch to master any time, but the PR cannot be merged into master until test_all() passes on Travis
(we will see the tests pass on the merge screen, which is more what I actually wanted. Actually preventing a merge is only possible with a pro account)
Explicit override to merge a PR even when tests don't pass should be possible, in case Travis is having issues. I think Github provides an override option by default, so likely nothing to do on this one other than check that the override exists.
(not possible without paying for pro account)
PipEnv to manage dependencies
(I implemented pipenv+pyenv on my machine, so there is a working Pipfile in the directory. However, using unittest by itself there are no dependencies and travis only takes a few seconds. The pipenv implementation was sufficiently difficult that I didn't want to include it in everyone's test process yet, and it will likely slow the build process down significantly. Postponing further work on it until we need it.)
And one I implemented more than the ticket spec'd:
As we understand the project parts better, we should be able to replace stubbed functions with appropriate calls to test the project's different parts (.e.g, expo test for mobile)
(Python testing works in ml and api directories with a few sample tests set up. Plus, I understood the mobile parts well enough to fully implement them. UI snapshot testing active. Pow!)
This potentially replaces #32, #21, #48, #20, #46, #33, #34, #35, #36,#29, #51 Also #25, #36 would need upates to remove "build" language, and just keep "test". There may be other tickets this eliminates, but those are all I saw for now.
Story As devs, we should have a stubbed CI flow for each part of the project, so we can easily plug in various tests to the CI once we have them running.
Acceptance Criteria
build.py test mobile
runs mobile test stubsbuild.py test ml
runs ML test stubsbuild.py test api
runs ML test stubsbuild.py test
runs all testsbuild.py test
output should be human-readable when run locallybuild.py test
output should be machine-readable when run by CIbuild.py test
expo test
for mobile)Depends on:
57
Relates to: Slack message:
Github flow diagram (though the order is slightly different):