Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Travis: add a check against false positives #7

Merged
merged 1 commit into from
Aug 28, 2019

Conversation

jrfnl
Copy link
Member

@jrfnl jrfnl commented Jul 30, 2019

This adds an additional check to the Travis build.

PR #2 added excludes to the ruleset to prevent false positives being generated when the ruleset would be run against the code of the polyfill itself.

As the polyfill may, of course, be updated over time, we need to ensure that these excludes are still sufficient.

This adds a dev dependency on the actual polyfill and a check to Travis to make sure that if the ruleset is run over the polyfill code, no errors are thrown.

Note: this check may start failing without notice because of changes in the polyfill, but that's exactly what this check is guarding against and will prevent us from releasing a version which doesn't have the right excludes in place.

In addition to this, an automatic weekly/monthly Travis run on master should be turned on to make sure this check is run on a semi-regular basis.
For now, I've turned an automatic monthly check on

Additionally:

  • I've also merged the duplicate cache key in the Travis script.
  • And the integration tests now run against an open-ended testVersion.

@jrfnl jrfnl added this to the 1.x Next milestone Jul 30, 2019
@jrfnl jrfnl requested a review from wimg July 30, 2019 15:24
@jrfnl jrfnl force-pushed the feature/travis-check-self-exclude branch from be7ac04 to f1974db Compare July 30, 2019 15:45
This adds an additional check to the Travis build.

PR 2 added `exclude`s to the ruleset to prevent false positives being generated when the ruleset would be run against the code of the polyfill itself.

As the polyfill may, of course, be updated over time, we need to ensure that these excludes are still sufficient.

This adds a `dev` dependency on the actual polyfill and a check to Travis to make sure that if the ruleset is run over the polyfill code, no errors are thrown.

**Note**: this check may start failing without notice because of changes in the polyfill, but that's exactly what this check is guarding against and will prevent us from releasing a version which doesn't have the right excludes in place.

In addition to this, an automatic weekly/monthly Travis run on `master` should be turned on to make sure this check is run on a semi-regular basis.
_For now, I've turned an automatic monthly check on_

Additionally:
* I've also merged the duplicate `cache` key in the Travis script.
* And the integration tests now run against an open-ended `testVersion`.
@jrfnl jrfnl force-pushed the feature/travis-check-self-exclude branch from f1974db to a262ff4 Compare August 24, 2019 15:31
@wimg wimg merged commit cc438b9 into master Aug 28, 2019
@delete-merged-branch delete-merged-branch bot deleted the feature/travis-check-self-exclude branch August 28, 2019 13:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants