Plugin needs and examples

disclaimer: contents of this page represent the opinions of @jaredly, and have largely yet to be tested and may be half-baked. Please discuss + modify as you see fit.

All per-repo settings should be configurable through a .strider.json config file (the name/format of the file is negotiable) in the repo or through the UI, stored in the DB. DB takes precedence over file config.

Global settings: currently we only support ENV variables. I lean more towards a file-based approach as things get complicated, because having >10 ENV variables just seems unwieldy to me (also, the ability to easily copy/modify/own your config seems like a plus).

docker

• setup very first before any setup is done to the environment, and definitely before the repo is cloned.
• save state (commit the image) after any environment setup has happened, and also after the repo has been cloned/updated (and dependancies have been installed), but before tests have been run.
• intercept all environment setup commands as "run" statements in a Dockerfile
  • would this cause huge problems? It would be really nice to be able to save them as "run" statements in a docker file as opposed to just doing docker run and then docker commit. Because then we would get all of the caching benefits. Of course, if a environment setup plugin tries to start a database in one command and then interact with it in another, it's hosed. But we could just say that interacting with a database doesn't belong in the environment setup section, but rather in the "dependencies" section.
• config
  • list of environment setup commands to run
  • "from" docker image
  • whether to start off from scratch each time, to start from the "post env setup", or from the "post clone" image

github-pr

• kickoff a build
• know whether the project will be sandboxed (by docker, for example) - this requires knowledge of installed plugins, and perhaps configuration options (whether the project is setup to use docker); this might be accessible from the database, but there's also the question of a VCd config file.
  • if yes, then test all pull requests
  • if no, test only those by "whitelisted" users.
    • to "whitelist" a user, can make a comment saying "[strider] Should I test this PR (and whitelist this contributor)?"
    • and then a owning user can reply either by saying "test" or "test and whitelist". If they don't say anything, then nothing happens.

heroku

• global config; API key for the user (or OAuth token)
• per-repo config; app destination
• deploy phase "git push heroku"

python

• perhaps as part of "env setup", install & augment the PATH for the specified version of python.
• run "pip install" for phase "dependancies"
• run "python setup.py test" for phase "test"
• per-repo config (in file + UI) for python version to install

nodejs

• perhaps as part of "env setup", install & augment the PATH for the specified version of python.
• run "npm install" : dependancies
• run "npm test" : test
• per-repo config (in file + UI) for what version of nodejs

Sauce Labs

• just needs to get running before the tests start

phantomjs

• environment setup stage, install phantomjs
• ? but what if we only know to install phantomjs after we've cloned the repo (because of a config file)? Same could well go for a "nodejs" or "python" plugin, that wants ideally to have the binary installation be part of the "environment setup" phase (so it could be committed by docker, for instance).

possible solution: grab the .strider.json just using the github contents api, parse it, and then proceed from there. I actually quite like this idea. This would allow for some pretty great performance gains on the docker side of things, and for any other plugins that need to be "pre-clone".

Questions

• Would it be useful for plugins to be able to specify themselves as "opt-in" or "opt-out"?
  • if a plugin is present, and declares itself to be "opt-in" then the user has to manually enable it for each desired repository. Otherwise it will default on.