Now with full js/jsx/coffee/hbs/scss goodness \o/
If your commit ONLY touches js/jsx/coffee/hbs/scss/views/controllers or
specific whitelisted things, and doesn't touch global-y bundles or
layouts, then your commit may** be selinimized. That means it will only
run the selenium specs that care about those files.
If you touch lib, or gems, or models, or any global-y stuff, all the specs
will still run.
Also add the ability to override what we selinimize against when testing
changes to selinimum.
**Note that actual selinimization depends on a post-merge build having
succeeded for the parent (or a near ancestor). If the post-merge build
failed, or your build starts before it finishes, or there are
unselinimizable changes between your commit and the nearest ancestor with
selinimum stats, then your commit will not be selinimized :'(
See 4a83f6b6 for the full story.
Test Plan:
* Specs should pass on this commit
* It should not be selinimized because we touch package.json
* See dependent test commits where selinimization happens
Change-Id: I62c78c316876aaff07514a0f460ff4d608dac494
Reviewed-on: https://gerrit.instructure.com/65082
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Reviewed-by: Derek Bender <djbender@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
What is this?
=============
Selinimum speeds up selenium by only running the specs it needs to for
your commit (iff it can safely determine that). For the purposes of the
initial implementation, that means that if your commit ONLY affects:
1. controllers (but not ApplicationController)
2. views (but not shared / layouts)
3. misc whitelisted stuff (images, .md files, etc.)
then it will only run the selenium specs that actually exercise those.
If your commit touches ANYTHING else (models, lib, etc.), all selenium
specs will run.
But wait, there's more!
=======================
Very soon selinimum will also handle:
1. js/coffee/jsx/hbs (except in the common bundle)
2. scss (except in the common bundle)
We already capture which bundles get used by each spec (see Capture), we
just need to correlate that with the individual files via a dependency
graph (probably using madge and sass-graph)
How does it work?
=================
The new post-merge selenium build will run all the specs with selinimum
capturing enabled. This records any controllers/views/js_bundle/css_bundle
that gets used in the course of each selenium spec, and stores a bunch of
data in S3.
Then when your patchset build runs, it will run Selinimum.minimize (via
corresponding tweak in rspect repo) on the list of spec files. If your
commit's dependents can be fully inferred and synthesized with the spec
dependency data from S3, only the relevant specs will actually be run.
Test Plan
=========
This commit doesn't actually cause selinimum to run on jenkins; that
requires some rspect changes and jenkins config. Refer to the test plan
here: https://gerrit.instructure.com/#/c/58088/
Change-Id: I991574c327a3a580c6fdc3ca3797dcfe0490a096
Reviewed-on: https://gerrit.instructure.com/58085
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Jon Jensen