Fail fast strategy for JSHint/JSCS/ESLint tests

Open
#100 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
javascript
Domain
ci-cd, testing-qa

Research direction

No files are named; start by locating the Travis CI and ember-try configuration that invokes JSHint, JSCS, ESLint, and try:each. Trace how lint commands enter each dependency matrix, then verify that lint runs once before the matrix, stops the build on failure, and is excluded from subsequent runs.

Written by the indexing model from the issue text.

Description

Just had the following happen: pushed a commit that accidentally had two consecutive blank lines in a file, which is a violation of a JSCS rule (ember-suave). The build took quite some time, just to show that a single JSCS test was failing for all ember versions (1.13 - 2.8 + beta + canary). Not only does this hamper developer productivity, it also puts a considerable amount of unnecessary burden on the CI infrastructure (Travis in this case).

Since JSHint/JSCS/ESLint tests won't depend on any dependencies, a) it seems unnecessary to run them in every try:each run and b) it could make sense to have them run once before any "real" tests.

So a "fail fast, fail early" strategy, which I guess is a pretty common CI best practice, could be in this case:

  1. run all JSHint/JSCS/ESLint tests with the default deps
  2. If that fails -> exit (non zero code)
  3. run try:each, with JSHint/JSCS/ESLint tests excluded

I guess you could make 1+3 happen with a custom config, not sure about 2? And what do you think about this approach, maybe this could become the default?

Dominant language
JavaScript
Stars
180
Forks
57
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ember-cli/ember-try

All issues in ember-cli/ember-try

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.