This runs faster and allows for future improvements.
Similar to the linter workflow, we remove the Circle-CI-specific stuff
from the file in tools/scripts/, and into .github/workflows/.
We use another external action (tj-actions/verify-changed-files) to check
that generating the tests didn't create any new changes. This is basically
a companion action to the tj-actions/changed-files used in the linter job.
After the previous commit, it doesn't do much, only passes the linting
exceptions file on the command line. Instead, make the lint.exceptions
file the default for that argument (if it exists), and remove the shell
script.
This runs faster and allows for future improvements.
I'm following a general principle of keeping code that isn't portable
between CI providers inside the config file for the CI provider. So in
this case we remove the Circle-CI-specific stuff from the file in
tools/scripts/, and into .github/workflows/. We use an external action
(tj-actions/changed-files) to gather the list of files to lint.
We do not use these anymore. Generated tests are included in PRs and not
deployed separately. The deploy key encryption relies on TravisCI which we
don't use anymore, anyway.
Prior to this patch, the CircleCI continuous integration environment was
configured to report test failures in a negative light, displaying red
cross-marks and reporting that "some checks were not successful" in
commits and GitHub Pull Requests which included them.
The passing/failing status of tests does not influence their
desirability for Test262. (In practice, engines very commonly fail
newly-contributed tests.)
Although these conflicting interpretations does not technically
interfere with the maintainers' ability to merge new contributions, it
does create confusion for many contributors who interpreted the UI as a
rejection of their work.
In addition, this behavior made it impossible to distinguish between the
benign test failures and disruptive infrastructural problems (e.g. the
crashing of engines).
Reconfigure the continuous integration environment to accept passing and
failing tests equally, and to only report a problem when the Test262
project's testing infrastructure behaves unexpectedly.
the double dot gets only commits not in the left side of the double dot.
The right side assumes HEAD.
This will allow us to fetch the correct list of new or modified files in the current branch.
This makes it possible to run the script locally even if `TRAVIS_PULL_REQUEST` is not set.
Currently, it results in an error:
tools/scripts/ci_build.sh: line 2: [: !=: unary operator expected
This script is intended to identify common test file formatting errors
prior to their acceptance into the project. It is designed to support
future extensions for additional validation rules.
Philip Chimento
Mike Pennisi
Rick Waldron
Leo Balter
Mathias Bynens