[Total Automation] CI/CD for `autobot`

[jmuchovej]

Just a note, when referring to groups... groups := {intelligence, core, data-science, supplementary}

Feature Request, for autobot

Description Whenever new features are added to autobot, run unit-tests to check for code-breaking changes on the incoming PR.

Needs

Flesh out tests/

• [ ] Check all directory creation (with respect to semesters as well as individual meetings)
  • [ ] For each group repo in groups
  • [ ] For each group website directory in groups
• [ ] Check Kaggle Kernel push continues functioning
• [ ] Check that Facebook banner generation works
  • Probably just needs a binary/checksum diff on a known, correct, image.
• [ ] Check that NotebookExporter produces...
  • [ ] Valid "non-solution" notebook
  • [ ] Valid website entry

Initial Comments

• Recommendations We currently us Travis CI to perform the website rebuilds. Travis is great, but is doesn't integrate with GitHub organizations (unless we pay for it). Check out GitHub Actions and see if we can use this, initially, for unit-testing.
• Based on the performance of GitHub Actions, let's try generalizing to #38? A huge problem with Travis was that we had no way to properly cache the build image, so each PR would take 10-15min to run. If there's no way around this, fine – but the actual tests should take a few minutes, so if we have a way to just rely on running the tests, that's definitely ideal!

[Haugf]

Hey John, we're thinking about adding a tests/ folder under autobot/, can we go over making and testing these unit tests later?

[jmuchovej]

hmm, so... looking at StackOverflow and at py.test... it's kinda, "up to us" to organize the folders. personally, behind the idea of throwing all the tests into a mirrored directory structure that's separate from autobot's source.

so... it would look something like this:

...
autobot
tests  <---
setup.py
...

also, would be useful to get a summary of unittest vs py.test, never used the latter; so i'm unsure, but it seems like it's a better library than unittest.

[Haugf]

pyTest has some self explanatory syntax and it is also the default test package for git actions.

I think this is the better choice

[jmuchovej]

alright, sweet. try to keep track of edits/changes in the conda environment files in envs/?

[Haugf]

Are the conda environment files the linux and macos .yml files?

[jmuchovej]

Are the conda environment files the linux and macos .yml files?

yep! ignore anything else in that folder, for now – i think the "requirements" that show up are for conda explicitly (since you can use pip there, but please do so only as a last resort.)

[jmuchovej]

https://github.com/ucfai/bot/blob/ebfca5e03b9c115b27ffc68b4635efa4f0da73bc/.github/workflows/docker.yml#L1

Building the environment in a Docker container that's released to:

• https://docker.pkg.github.com.com/ucfai/bot/env
• https://docker.pkg.github.com.com/ucfai/bot/development
• https://docker.pkg.github.com.com/ucfai/bot/production