With the addition of inter-process-messaging npm deps to the cache, but
no change in the shrinkwrap checksum, the cache will not get updated
until we either change any of the shrinkwrap files or change the cache
keys. So I'm bumping the version numbers to do the latter.
Without the `--phantom` flag passed to the `meteor self-test` command, the
client tests within those self-test test definitions will only be run on
Chrome Headless.
We might want to consider making it the default, so it runs without an
additional argument on local development as well, but this will make sure
that these important Phantom tests run in CircleCI to ensure we're testing
both modern and legacy browsers (of which the later group includes
PhantomJS, in all its "legacy" glory).
cc @hwillson @benjamn for input.
There have been a number of occasions where I have gone to bump the
Meteor docs to the next major version, only to find that the docs
deployment (which occurs in a separate repository; found at
https://github.com/meteor/docs) fails due to code-refactoring which has
taken place in its submodule (`code`, which is this Meteor codebase).
In order to provide early warning when a JSDoc declaration in the Meteor
code is going to (eventually) break the docs deployment which occurs in
a separate repository (https://github.com/meteor/docs), this commit
introduces a simple checkout and doc generation, in the same manner as
the docs would in its own repository, within the CircleCI workflow.
It's been configured in a way where it will not stop the normal Meteor
test-suite from running, however it will show a separate indicator on
GitHub pull-requests as to whether the generation of docs was successful
or not.
* Add a self-test skip option
Meteor's CI infrastructure is configured to exclude certain
`self-test`'s on each run. These excludes are specified in
each CI environment's config file, and included when running
`meteor self-test`. Developers running `meteor self-test`
locally however are not using these excludes by default,
so developer's have to manually look up the current exclude
list from one of the CI configs, then add these excludes to
their own `meteor self-test` call manually.
This commit adds a new `skip` option to Meteor's `self-test`
system, that can be used to skip adding/running a defined
`self-test` (similar in concept to Mocha's `skip` feature).
This provides a way to skip the running of older
`self-test`'s that are no longer needed, but allows them to
be preserved in the `self-test` suite, for future reference.
With this functionality in place, and the older test suites
updated to use it, Meteor's base CI excludes no longer need
to be maintained in their respective config files. The
excludes are all managed at the source (the test definition),
and can be leveraged by anyone/anything calling
`meteor self-test`.
* Log message describing skipped test
* Add manually-ignored count to self-test summary
* Small comment correction
* History.md entry with PR link
In order to install Gradle, which is required for Cordova tests to run
in the Meteor self-test suite, this image slightly builds upon the
CircleCI image we'd been using previously.
This is potentially a big change, though it should (with any luck) make
tests faster, and allow us to better test Cordova functionality (at least
as far as Android is concerned). For example, if this works, we won't have
to mark the "cordova builds with server options" self-test "slow" again,
which would (re)disable it during Circle CI test runs.
cc @abernix @hwillson
This adds a memoized helper function for detecting Emacs throughout the
CLI tool and automatically resorts to "ProgressDisplayStatus" mode when
Emacs is enabled.
In my tests with both Emacs 22 and 27, this nearly doubled performance
when using Meteor from within the Emacs shell (i.e. `M-x shell`).
While running the tests three times might make a lot of sence in CI
environments, it certainly slows things down in development, especially
when you've failed a test on purpose, but still have to wait for it to
run three times to get the output.
This not only implements the `--retries` flag, but also activates it in
both CircleCI and AppVeyor test suites.
While this was necessary in previous versions of Meteor, as of 1.6 the
`self-test` tooling will automatically install the dependencies it needs
at runtime.
Not only does this allow the installation to be avoided when tests using
those facilities aren't invoked, it also allows us to reliably install
the same version of these npms, rather than falling back to the
`latest` npm tag on each CI run.
This was preventing the proper group name from being displayed on test
group "2", though the test was still working properly.
Refs: https://github.com/meteor/meteor/pull/9190 where it was spotted.
Since 8c70716954, optimistic file watching
uses far fewer file descriptors, so the original motivation of setting
this environment variable no longer holds.
A while back we switched from running `./meteor --get-ready`, a command
that takes many minutes and sometimes runs out of memory, to just running
`./meteor --help` to prepare for self-tests.
The hope was that `./meteor --help` would fail less often, and the work
that would have been done by `./meteor --get-ready` would be spread out
through the actual tests. This helped, I think, but we've been seeing
quite a few self-test failures due to unreliable timing of the actual
tests, so I'd like to try shifting the balance back.
I'm pushing this to the branch with our patched Node 4.8.4, because
that branch should have a lower risk of segmentation faults, which may
allow `./meteor --get-ready` to succeed more often.
This is a bit of a shot in the dark, admittedly, but I want to see what
happens. 🤞
This switches Meteor's CircleCI builds from Circle 1.0 to Circle 2.0 which
has a bit more control over the workflow.
Currently, this eliminates the existing ci.sh script which was already a bit
incompatible when I was attempting to run Windows builds on another environment.
It's possible that we should change this to a Node.js wrapper script.
Other improvements:
- We now store Core Dumps in build artifacts. CircleCI 2.0 advertised this as
one of the features of CircleCI 2.0, but honestly, it was far from
straightforward. Perhaps if we were using another Dockerimage, but it was
far from as easy as flipping a switch. In addition to saving the Core Dump,
this also saves the Node.js binary which was included in the Dev Bundle. This
can be very handy for post-mortem debugging with tools like lldb, gdb, or mdb.
- Memory usage is now logged throughout the build via a background process which
logs `ps` output to a file which is persisted to the build artifacts. This
should help identify if builds are terminating for some environmental reason.
