Since this test utilizes the `testWithAllClients` technique, which runs
the tests in various clients/browsers, it's necessary for the tests
`Sandbox` to define `clients`, otherwise the function within
`testWithAllClients` will not be executed at all. This was causing this
particular test to always return success (it was running without failure
on exactly zero clients).
Also the technique of setting `this.baseTimeout` appeared to cause
problems, likely because it overrides various other values instead of
using `waitSecs` (we don't use the `baseTimeout` technique in other
places within self-tests either).
Discovered during testing, as mentioned in
https://github.com/meteor/meteor/pull/9439#pullrequestreview-83139232.
This restores the behavior of 8c70716954 by
default, with the option of disabling the prioritized file watching system
by setting METEOR_WATCH_PRIORITIZE_CHANGED explicitly to "false".
The self-tests where the environment variable is explicitly set form a
nice to-do list of tests that should be improved to be more robust to cope
with differences in file watcher timing.
Helps with #8648 and similar issues.
This test has been the primary source of test suite unreliability in
recent weeks. By marking it "slow" I'm effectively disabling it on
CircleCI, which I think is acceptable because (1) it is, in fact, quite
slow; (2) it passes locally on Linux; and (3) it depends on the timing of
file change notifications, which is a recipe for test flakiness due to the
general non-determinism of file watching, but not necessarily a sign of a
broken developer experience.
Like other "slow" tests, I will keep running this test locally via
meteor self-test --slow 'javascript hot code push'
as part of the manual QA testing that we do.
This test had been somewhat flaky. It seems to be less flaky now.
Changes include:
- Trying to not send the client->server logging RPC if the client is
about to reload due to autoupdate
- Making sure that the client doesn't send anything at all until a
little bit after starting, in order to make the ordering of messages
between tool-printed and server-printed messages more predictable
Also updated from standard-app-packages to meteor-tool.
This will be useful when we want to be smart with windows file paths later
Also, all of the file calls are asynchronous with fibers now, which comes with
many benefits.
This is a combination of 23 commits. Original messages:
Wrap a large number of fs calls inside files.*
Convert a few more fs calls to files.*
More moving fs.* to files
Implement read/write streams and open/read/close
Get rid of fs from auth.js
Remove fs and unused imports from catalog-local and catalog-remote
Remove unused imports from catalog.js
Replace a whole lot of fs calls
Fix error
Migrate a lot more fs. calls to files.
Add a temporary symlink method
Convert old test to files.*
Use files.pathX instead of path.x everywhere
Replace path.x to files.pathX in tests
Small fixes to files.js and one rename
Make cleanup run in a fiber
Make wrapping functions take function name in case we need it
Add some timeouts and stuff to HCP tests
wrapFsFunc also makes a sync version of the function
Sometimes you just don't want to yield!
Make sure JsImage readFromDisk doesn't yield
Remove unused imports from npm test
Change order of test now that some things don't yield
Fix missing files import, and add a debug error printout
This reimplements functionality that had been removed as part of the
`isopack-cache` branch refactoring.
Information about package changes is encapsulated inside a
PackageMapDelta object on the ProjectContext. It is the responsibility
of the command that prepares the ProjectContext to choose to call
projectContext.packageMapDelta.displayOnConsole at the appropriate time
if it wishes to display changes.
Part of #3006.
If Autoupdate.autoupdateVersion is set outside of the Autoupdate
package, we wouldn't notify the client of the new version. This
patch simplifies the updating logic by only having one document
per version type.
Regression introduced by the CSS watching code (specifically, f230eba62)
by the sourceIsWatched check. We need to be able to tell the difference
between "source handler didn't do anything because there was an error"
and "source handler didn't do anything because it's web-specific and
this is an os arch".
A simple fix would have been to interpret compileStep.error as
"sourceIsWatched = true", but I didn't think of that until after doing
it the slightly more complicated but more precise way :)
Also, ensure that if the runner rebuilds the client and there's an
error, it properly kills the app process (and the watchers and the
keepalive interval, etc).
presumably this was previously tested on a checkout where
tools/tests/apps/hot-code-push-test/client existed, but git doesn't know
how to check in empty directories. (another alternative would be to
check in a dummy file in that directory)
