py3: Switch almost all shebang lines to use `python3`.
This causes `upgrade-zulip-from-git`, as well as a no-option run of
`tools/build-release-tarball`, to produce a Zulip install running
Python 3, rather than Python 2. In particular this means that the
virtualenv we create, in which all application code runs, is Python 3.
One shebang line, on `zulip-ec2-configure-interfaces`, explicitly
keeps Python 2, and at least one external ops script, `wal-e`, also
still runs on Python 2. See discussion on the respective previous
commits that made those explicit. There may also be some other
third-party scripts we use, outside of this source tree and running
outside our virtualenv, that still run on Python 2.
2017-08-02 23:15:16 +02:00
|
|
|
#!/usr/bin/env python3
|
2015-10-26 17:11:44 +01:00
|
|
|
|
2016-08-29 01:02:03 +02:00
|
|
|
import argparse
|
2015-10-26 17:11:44 +01:00
|
|
|
import os
|
|
|
|
import sys
|
2017-05-25 20:12:33 +02:00
|
|
|
import json
|
2019-05-29 02:19:59 +02:00
|
|
|
import subprocess
|
|
|
|
import pyinotify
|
2015-10-26 17:11:44 +01:00
|
|
|
|
2019-04-22 22:59:11 +02:00
|
|
|
if False:
|
|
|
|
from typing import NoReturn
|
|
|
|
|
2017-02-05 21:24:28 +01:00
|
|
|
# check for the venv
|
|
|
|
from lib import sanity_check
|
|
|
|
sanity_check.check_venv(__file__)
|
|
|
|
|
2015-10-26 17:11:44 +01:00
|
|
|
sys.path.insert(0, os.path.join(os.path.dirname(__file__), '..'))
|
|
|
|
os.environ['DJANGO_SETTINGS_MODULE'] = 'zproject.settings'
|
|
|
|
from django.conf import settings
|
|
|
|
|
|
|
|
os.chdir(settings.DEPLOY_ROOT)
|
|
|
|
STATIC_PATH = 'static/'
|
|
|
|
|
2017-05-25 20:12:33 +02:00
|
|
|
|
tests: Clean up calls to tools/webpack.
Before this change, the way we loaded
webpack for various tools was brittle.
First, I addressed test-api and test-help-documentation.
These tools used to be unable to run standalone on a
clean provision, because they were (indirectly)
calling tools/webpack without the `--test` option.
The problem was a bit obscure, since running things
like `./tools/test-backend` or `./tools/test-all` in
your workflow would create `./var/webpack-stats-test.json`
for the broken tools (and then they would work).
The tools themselves weren't broken; they were the
only relying on the common `test_server_running` helper.
And even that helper wasn't broken; it was just that
`run-dev.py` wasn't respecting the `--test` option.
So I made it so that `./tools/run-dev` passes in `--test` to
`./tools/webpack`.
To confuse matters even more, for some reason Casper
uses `./webpack-stats-production.json` via various
hacks for its webpack configuration, so when I fixed
the other tests, it broke Casper.
Here is the Casper-related hack in zproject/test_settings.py,
which was in place before my change and remains
after it:
if CASPER_TESTS:
WEBPACK_FILE = 'webpack-stats-production.json'
else:
WEBPACK_FILE = os.path.join('var', 'webpack-stats-test.json')
I added similar logic in tools/webpack:
if "CASPER_TESTS" in os.environ:
build_for_prod_or_casper(args.quiet)
I also made the helper functions in `./tools/webpack` have
nicer names.
So, now tools should all be able to run standalone and not
rely on previous tools creating webpack stats files for
them and leaving them in the file system. That's good.
Things are still a bit janky, though. It's not completely
clear to me why `test-js-with-casper` should work off of
a different webpack configuration than the other tests.
For now most of the jankiness is around Casper, and we have
hacks in two different places, `zproject/test_settings.py` and
`tools/webpack` to force it to use the production stats
file instead of the "test" one, even though Casper uses
test-like settings for other things like which database
you're using.
2018-09-06 21:01:45 +02:00
|
|
|
def build_for_prod_or_casper(quiet):
|
2019-04-22 22:59:11 +02:00
|
|
|
# type: (bool) -> NoReturn
|
2016-10-16 07:27:55 +02:00
|
|
|
"""Builds for production, writing the output to disk"""
|
tests: Clean up calls to tools/webpack.
Before this change, the way we loaded
webpack for various tools was brittle.
First, I addressed test-api and test-help-documentation.
These tools used to be unable to run standalone on a
clean provision, because they were (indirectly)
calling tools/webpack without the `--test` option.
The problem was a bit obscure, since running things
like `./tools/test-backend` or `./tools/test-all` in
your workflow would create `./var/webpack-stats-test.json`
for the broken tools (and then they would work).
The tools themselves weren't broken; they were the
only relying on the common `test_server_running` helper.
And even that helper wasn't broken; it was just that
`run-dev.py` wasn't respecting the `--test` option.
So I made it so that `./tools/run-dev` passes in `--test` to
`./tools/webpack`.
To confuse matters even more, for some reason Casper
uses `./webpack-stats-production.json` via various
hacks for its webpack configuration, so when I fixed
the other tests, it broke Casper.
Here is the Casper-related hack in zproject/test_settings.py,
which was in place before my change and remains
after it:
if CASPER_TESTS:
WEBPACK_FILE = 'webpack-stats-production.json'
else:
WEBPACK_FILE = os.path.join('var', 'webpack-stats-test.json')
I added similar logic in tools/webpack:
if "CASPER_TESTS" in os.environ:
build_for_prod_or_casper(args.quiet)
I also made the helper functions in `./tools/webpack` have
nicer names.
So, now tools should all be able to run standalone and not
rely on previous tools creating webpack stats files for
them and leaving them in the file system. That's good.
Things are still a bit janky, though. It's not completely
clear to me why `test-js-with-casper` should work off of
a different webpack configuration than the other tests.
For now most of the jankiness is around Casper, and we have
hacks in two different places, `zproject/test_settings.py` and
`tools/webpack` to force it to use the production stats
file instead of the "test" one, even though Casper uses
test-like settings for other things like which database
you're using.
2018-09-06 21:01:45 +02:00
|
|
|
|
2018-04-28 13:11:05 +02:00
|
|
|
webpack_args = ['node', 'node_modules/.bin/webpack-cli',
|
|
|
|
'--config', 'tools/webpack.config.ts', '-p',
|
|
|
|
'--env', 'production']
|
|
|
|
if quiet:
|
|
|
|
webpack_args += ['--display', 'errors-only']
|
|
|
|
print('Starting webpack compilation')
|
2019-04-22 22:59:11 +02:00
|
|
|
os.execvp(webpack_args[0], webpack_args)
|
2015-10-26 17:11:44 +01:00
|
|
|
|
tests: Clean up calls to tools/webpack.
Before this change, the way we loaded
webpack for various tools was brittle.
First, I addressed test-api and test-help-documentation.
These tools used to be unable to run standalone on a
clean provision, because they were (indirectly)
calling tools/webpack without the `--test` option.
The problem was a bit obscure, since running things
like `./tools/test-backend` or `./tools/test-all` in
your workflow would create `./var/webpack-stats-test.json`
for the broken tools (and then they would work).
The tools themselves weren't broken; they were the
only relying on the common `test_server_running` helper.
And even that helper wasn't broken; it was just that
`run-dev.py` wasn't respecting the `--test` option.
So I made it so that `./tools/run-dev` passes in `--test` to
`./tools/webpack`.
To confuse matters even more, for some reason Casper
uses `./webpack-stats-production.json` via various
hacks for its webpack configuration, so when I fixed
the other tests, it broke Casper.
Here is the Casper-related hack in zproject/test_settings.py,
which was in place before my change and remains
after it:
if CASPER_TESTS:
WEBPACK_FILE = 'webpack-stats-production.json'
else:
WEBPACK_FILE = os.path.join('var', 'webpack-stats-test.json')
I added similar logic in tools/webpack:
if "CASPER_TESTS" in os.environ:
build_for_prod_or_casper(args.quiet)
I also made the helper functions in `./tools/webpack` have
nicer names.
So, now tools should all be able to run standalone and not
rely on previous tools creating webpack stats files for
them and leaving them in the file system. That's good.
Things are still a bit janky, though. It's not completely
clear to me why `test-js-with-casper` should work off of
a different webpack configuration than the other tests.
For now most of the jankiness is around Casper, and we have
hacks in two different places, `zproject/test_settings.py` and
`tools/webpack` to force it to use the production stats
file instead of the "test" one, even though Casper uses
test-like settings for other things like which database
you're using.
2018-09-06 21:01:45 +02:00
|
|
|
def build_for_dev_server(host, port, minify, disable_host_check):
|
2019-05-29 02:19:59 +02:00
|
|
|
# type: (str, str, bool, bool) -> None
|
2016-10-16 07:27:55 +02:00
|
|
|
"""watches and rebuilds on changes, serving files from memory via webpack-dev-server"""
|
tests: Clean up calls to tools/webpack.
Before this change, the way we loaded
webpack for various tools was brittle.
First, I addressed test-api and test-help-documentation.
These tools used to be unable to run standalone on a
clean provision, because they were (indirectly)
calling tools/webpack without the `--test` option.
The problem was a bit obscure, since running things
like `./tools/test-backend` or `./tools/test-all` in
your workflow would create `./var/webpack-stats-test.json`
for the broken tools (and then they would work).
The tools themselves weren't broken; they were the
only relying on the common `test_server_running` helper.
And even that helper wasn't broken; it was just that
`run-dev.py` wasn't respecting the `--test` option.
So I made it so that `./tools/run-dev` passes in `--test` to
`./tools/webpack`.
To confuse matters even more, for some reason Casper
uses `./webpack-stats-production.json` via various
hacks for its webpack configuration, so when I fixed
the other tests, it broke Casper.
Here is the Casper-related hack in zproject/test_settings.py,
which was in place before my change and remains
after it:
if CASPER_TESTS:
WEBPACK_FILE = 'webpack-stats-production.json'
else:
WEBPACK_FILE = os.path.join('var', 'webpack-stats-test.json')
I added similar logic in tools/webpack:
if "CASPER_TESTS" in os.environ:
build_for_prod_or_casper(args.quiet)
I also made the helper functions in `./tools/webpack` have
nicer names.
So, now tools should all be able to run standalone and not
rely on previous tools creating webpack stats files for
them and leaving them in the file system. That's good.
Things are still a bit janky, though. It's not completely
clear to me why `test-js-with-casper` should work off of
a different webpack configuration than the other tests.
For now most of the jankiness is around Casper, and we have
hacks in two different places, `zproject/test_settings.py` and
`tools/webpack` to force it to use the production stats
file instead of the "test" one, even though Casper uses
test-like settings for other things like which database
you're using.
2018-09-06 21:01:45 +02:00
|
|
|
|
|
|
|
# This is our most dynamic configuration, which we use for our
|
|
|
|
# dev server. The key piece here is that we identify changes to
|
|
|
|
# files as devs make edits and serve new assets on the fly.
|
2017-06-10 20:28:48 +02:00
|
|
|
webpack_args = ['node', 'node_modules/.bin/webpack-dev-server']
|
2018-04-25 21:16:08 +02:00
|
|
|
webpack_args += [
|
|
|
|
'--config',
|
|
|
|
'tools/webpack.config.ts',
|
2018-05-21 03:12:28 +02:00
|
|
|
'--allowed-hosts', ','.join([host, '.zulipdev.com', '.zulipdev.org']),
|
2018-04-25 21:16:08 +02:00
|
|
|
'--host', host,
|
|
|
|
'--port', port,
|
|
|
|
# We add the hot flag using the cli because it takes care
|
|
|
|
# of addition to entry points and adding the plugin
|
|
|
|
# automatically
|
|
|
|
'--hot'
|
|
|
|
]
|
2017-06-10 20:28:48 +02:00
|
|
|
if minify:
|
|
|
|
webpack_args.append('--optimize-minimize')
|
2018-04-24 15:27:15 +02:00
|
|
|
if disable_host_check:
|
|
|
|
webpack_args.append('--disable-host-check')
|
2019-05-29 02:19:59 +02:00
|
|
|
|
2019-06-01 02:05:56 +02:00
|
|
|
try:
|
|
|
|
webpack_process = subprocess.Popen(webpack_args)
|
2019-05-29 02:19:59 +02:00
|
|
|
|
2019-06-01 02:05:56 +02:00
|
|
|
class WebpackConfigFileChangeHandler(pyinotify.ProcessEvent):
|
|
|
|
def process_default(self, event):
|
|
|
|
# type: (pyinotify.Event) -> None
|
|
|
|
nonlocal webpack_process
|
|
|
|
print('Restarting webpack-dev-server due to config changes...')
|
|
|
|
webpack_process.terminate()
|
|
|
|
webpack_process.wait()
|
|
|
|
webpack_process = subprocess.Popen(webpack_args)
|
2019-05-29 02:19:59 +02:00
|
|
|
|
|
|
|
watch_manager = pyinotify.WatchManager()
|
|
|
|
event_notifier = pyinotify.Notifier(watch_manager, WebpackConfigFileChangeHandler())
|
|
|
|
for file in ['webpack.config.ts', 'webpack-helpers.ts', 'webpack.assets.json']:
|
|
|
|
filepath = os.path.join(os.path.dirname(__file__), file)
|
|
|
|
watch_manager.add_watch(filepath, pyinotify.IN_MODIFY)
|
|
|
|
event_notifier.loop()
|
|
|
|
finally:
|
|
|
|
webpack_process.terminate()
|
|
|
|
webpack_process.wait()
|
2015-10-26 17:11:44 +01:00
|
|
|
|
tests: Clean up calls to tools/webpack.
Before this change, the way we loaded
webpack for various tools was brittle.
First, I addressed test-api and test-help-documentation.
These tools used to be unable to run standalone on a
clean provision, because they were (indirectly)
calling tools/webpack without the `--test` option.
The problem was a bit obscure, since running things
like `./tools/test-backend` or `./tools/test-all` in
your workflow would create `./var/webpack-stats-test.json`
for the broken tools (and then they would work).
The tools themselves weren't broken; they were the
only relying on the common `test_server_running` helper.
And even that helper wasn't broken; it was just that
`run-dev.py` wasn't respecting the `--test` option.
So I made it so that `./tools/run-dev` passes in `--test` to
`./tools/webpack`.
To confuse matters even more, for some reason Casper
uses `./webpack-stats-production.json` via various
hacks for its webpack configuration, so when I fixed
the other tests, it broke Casper.
Here is the Casper-related hack in zproject/test_settings.py,
which was in place before my change and remains
after it:
if CASPER_TESTS:
WEBPACK_FILE = 'webpack-stats-production.json'
else:
WEBPACK_FILE = os.path.join('var', 'webpack-stats-test.json')
I added similar logic in tools/webpack:
if "CASPER_TESTS" in os.environ:
build_for_prod_or_casper(args.quiet)
I also made the helper functions in `./tools/webpack` have
nicer names.
So, now tools should all be able to run standalone and not
rely on previous tools creating webpack stats files for
them and leaving them in the file system. That's good.
Things are still a bit janky, though. It's not completely
clear to me why `test-js-with-casper` should work off of
a different webpack configuration than the other tests.
For now most of the jankiness is around Casper, and we have
hacks in two different places, `zproject/test_settings.py` and
`tools/webpack` to force it to use the production stats
file instead of the "test" one, even though Casper uses
test-like settings for other things like which database
you're using.
2018-09-06 21:01:45 +02:00
|
|
|
def build_for_most_tests():
|
2017-12-13 19:38:15 +01:00
|
|
|
# type: () -> None
|
2017-05-25 20:12:33 +02:00
|
|
|
"""Generates a stub asset stat file for django so backend test can render a page"""
|
tests: Clean up calls to tools/webpack.
Before this change, the way we loaded
webpack for various tools was brittle.
First, I addressed test-api and test-help-documentation.
These tools used to be unable to run standalone on a
clean provision, because they were (indirectly)
calling tools/webpack without the `--test` option.
The problem was a bit obscure, since running things
like `./tools/test-backend` or `./tools/test-all` in
your workflow would create `./var/webpack-stats-test.json`
for the broken tools (and then they would work).
The tools themselves weren't broken; they were the
only relying on the common `test_server_running` helper.
And even that helper wasn't broken; it was just that
`run-dev.py` wasn't respecting the `--test` option.
So I made it so that `./tools/run-dev` passes in `--test` to
`./tools/webpack`.
To confuse matters even more, for some reason Casper
uses `./webpack-stats-production.json` via various
hacks for its webpack configuration, so when I fixed
the other tests, it broke Casper.
Here is the Casper-related hack in zproject/test_settings.py,
which was in place before my change and remains
after it:
if CASPER_TESTS:
WEBPACK_FILE = 'webpack-stats-production.json'
else:
WEBPACK_FILE = os.path.join('var', 'webpack-stats-test.json')
I added similar logic in tools/webpack:
if "CASPER_TESTS" in os.environ:
build_for_prod_or_casper(args.quiet)
I also made the helper functions in `./tools/webpack` have
nicer names.
So, now tools should all be able to run standalone and not
rely on previous tools creating webpack stats files for
them and leaving them in the file system. That's good.
Things are still a bit janky, though. It's not completely
clear to me why `test-js-with-casper` should work off of
a different webpack configuration than the other tests.
For now most of the jankiness is around Casper, and we have
hacks in two different places, `zproject/test_settings.py` and
`tools/webpack` to force it to use the production stats
file instead of the "test" one, even though Casper uses
test-like settings for other things like which database
you're using.
2018-09-06 21:01:45 +02:00
|
|
|
|
|
|
|
# Tests like test-backend, test-api, and test-home-documentation use
|
|
|
|
# our "test" configuration. The one exception is Casper, which uses
|
|
|
|
# our production configuration.
|
|
|
|
#
|
|
|
|
# It's not completely clear why we don't also use the same
|
|
|
|
# configuration for ALL tests, but figuring out the full history here
|
|
|
|
# was out of the scope of the effort here to add some comments and
|
|
|
|
# clean up names.
|
2017-05-25 20:12:33 +02:00
|
|
|
entries = {}
|
|
|
|
with open('tools/webpack.assets.json') as json_data:
|
|
|
|
for entry in json.load(json_data).keys():
|
|
|
|
entries[entry] = [{
|
|
|
|
"name": "%s.js" % (entry,),
|
|
|
|
"publicPath": "http://localhost:3000/webpack-stub/%s-stubentry.js" % (entry,),
|
|
|
|
"path": "/stubfolder/%s-stubfile.js" % (entry,)
|
|
|
|
}]
|
|
|
|
stat_data = {
|
|
|
|
"status": "done",
|
|
|
|
"chunks": entries
|
|
|
|
}
|
2017-07-18 21:47:47 +02:00
|
|
|
directory = 'var'
|
2017-05-25 20:12:33 +02:00
|
|
|
if not os.path.exists(directory):
|
|
|
|
os.makedirs(directory)
|
|
|
|
with open(os.path.join(directory, 'webpack-stats-test.json'), 'w') as outfile:
|
|
|
|
json.dump(stat_data, outfile)
|
|
|
|
|
|
|
|
|
2016-08-29 01:02:03 +02:00
|
|
|
parser = argparse.ArgumentParser()
|
2017-05-25 20:12:33 +02:00
|
|
|
parser.add_argument('--test',
|
|
|
|
action='store_true', dest='test', default=False,
|
|
|
|
help='generate a stub webpack-stats.json file (for backend testing)')
|
2018-04-28 13:11:05 +02:00
|
|
|
parser.add_argument('--quiet',
|
|
|
|
action='store_true', dest='quiet', default=False,
|
|
|
|
help='Minimizes webpack output while running')
|
2016-08-29 01:02:03 +02:00
|
|
|
parser.add_argument('--watch',
|
2016-12-11 14:30:45 +01:00
|
|
|
action='store_true', dest='watch', default=False,
|
|
|
|
help='watch for changes to source files (for development)')
|
2017-07-16 21:14:03 +02:00
|
|
|
parser.add_argument('--host',
|
|
|
|
action='store', dest='host',
|
|
|
|
default='127.0.0.1', help='set the host for the webpack server to run on')
|
2016-08-29 01:02:03 +02:00
|
|
|
parser.add_argument('--port',
|
2016-12-11 14:30:45 +01:00
|
|
|
action='store', dest='port',
|
|
|
|
default='9994', help='set the port for the webpack server to run on')
|
2017-06-10 20:28:48 +02:00
|
|
|
parser.add_argument('--minify',
|
|
|
|
action='store_true', dest='minify', default=False,
|
|
|
|
help='Minify and optimize the assets (for development)')
|
2018-04-24 15:27:15 +02:00
|
|
|
parser.add_argument('--disable-host-check',
|
|
|
|
action='store_true', dest='disable_host_check', default=None,
|
|
|
|
help='Disable host check for webpack-dev-server')
|
2016-04-13 04:19:56 +02:00
|
|
|
|
2017-05-25 20:12:33 +02:00
|
|
|
args = parser.parse_args()
|
tests: Clean up calls to tools/webpack.
Before this change, the way we loaded
webpack for various tools was brittle.
First, I addressed test-api and test-help-documentation.
These tools used to be unable to run standalone on a
clean provision, because they were (indirectly)
calling tools/webpack without the `--test` option.
The problem was a bit obscure, since running things
like `./tools/test-backend` or `./tools/test-all` in
your workflow would create `./var/webpack-stats-test.json`
for the broken tools (and then they would work).
The tools themselves weren't broken; they were the
only relying on the common `test_server_running` helper.
And even that helper wasn't broken; it was just that
`run-dev.py` wasn't respecting the `--test` option.
So I made it so that `./tools/run-dev` passes in `--test` to
`./tools/webpack`.
To confuse matters even more, for some reason Casper
uses `./webpack-stats-production.json` via various
hacks for its webpack configuration, so when I fixed
the other tests, it broke Casper.
Here is the Casper-related hack in zproject/test_settings.py,
which was in place before my change and remains
after it:
if CASPER_TESTS:
WEBPACK_FILE = 'webpack-stats-production.json'
else:
WEBPACK_FILE = os.path.join('var', 'webpack-stats-test.json')
I added similar logic in tools/webpack:
if "CASPER_TESTS" in os.environ:
build_for_prod_or_casper(args.quiet)
I also made the helper functions in `./tools/webpack` have
nicer names.
So, now tools should all be able to run standalone and not
rely on previous tools creating webpack stats files for
them and leaving them in the file system. That's good.
Things are still a bit janky, though. It's not completely
clear to me why `test-js-with-casper` should work off of
a different webpack configuration than the other tests.
For now most of the jankiness is around Casper, and we have
hacks in two different places, `zproject/test_settings.py` and
`tools/webpack` to force it to use the production stats
file instead of the "test" one, even though Casper uses
test-like settings for other things like which database
you're using.
2018-09-06 21:01:45 +02:00
|
|
|
if "CASPER_TESTS" in os.environ:
|
|
|
|
build_for_prod_or_casper(args.quiet)
|
|
|
|
elif args.test:
|
|
|
|
build_for_most_tests()
|
2017-05-25 20:12:33 +02:00
|
|
|
elif args.watch:
|
tests: Clean up calls to tools/webpack.
Before this change, the way we loaded
webpack for various tools was brittle.
First, I addressed test-api and test-help-documentation.
These tools used to be unable to run standalone on a
clean provision, because they were (indirectly)
calling tools/webpack without the `--test` option.
The problem was a bit obscure, since running things
like `./tools/test-backend` or `./tools/test-all` in
your workflow would create `./var/webpack-stats-test.json`
for the broken tools (and then they would work).
The tools themselves weren't broken; they were the
only relying on the common `test_server_running` helper.
And even that helper wasn't broken; it was just that
`run-dev.py` wasn't respecting the `--test` option.
So I made it so that `./tools/run-dev` passes in `--test` to
`./tools/webpack`.
To confuse matters even more, for some reason Casper
uses `./webpack-stats-production.json` via various
hacks for its webpack configuration, so when I fixed
the other tests, it broke Casper.
Here is the Casper-related hack in zproject/test_settings.py,
which was in place before my change and remains
after it:
if CASPER_TESTS:
WEBPACK_FILE = 'webpack-stats-production.json'
else:
WEBPACK_FILE = os.path.join('var', 'webpack-stats-test.json')
I added similar logic in tools/webpack:
if "CASPER_TESTS" in os.environ:
build_for_prod_or_casper(args.quiet)
I also made the helper functions in `./tools/webpack` have
nicer names.
So, now tools should all be able to run standalone and not
rely on previous tools creating webpack stats files for
them and leaving them in the file system. That's good.
Things are still a bit janky, though. It's not completely
clear to me why `test-js-with-casper` should work off of
a different webpack configuration than the other tests.
For now most of the jankiness is around Casper, and we have
hacks in two different places, `zproject/test_settings.py` and
`tools/webpack` to force it to use the production stats
file instead of the "test" one, even though Casper uses
test-like settings for other things like which database
you're using.
2018-09-06 21:01:45 +02:00
|
|
|
build_for_dev_server(args.host, args.port, args.minify, args.disable_host_check)
|
2016-04-13 04:19:56 +02:00
|
|
|
else:
|
tests: Clean up calls to tools/webpack.
Before this change, the way we loaded
webpack for various tools was brittle.
First, I addressed test-api and test-help-documentation.
These tools used to be unable to run standalone on a
clean provision, because they were (indirectly)
calling tools/webpack without the `--test` option.
The problem was a bit obscure, since running things
like `./tools/test-backend` or `./tools/test-all` in
your workflow would create `./var/webpack-stats-test.json`
for the broken tools (and then they would work).
The tools themselves weren't broken; they were the
only relying on the common `test_server_running` helper.
And even that helper wasn't broken; it was just that
`run-dev.py` wasn't respecting the `--test` option.
So I made it so that `./tools/run-dev` passes in `--test` to
`./tools/webpack`.
To confuse matters even more, for some reason Casper
uses `./webpack-stats-production.json` via various
hacks for its webpack configuration, so when I fixed
the other tests, it broke Casper.
Here is the Casper-related hack in zproject/test_settings.py,
which was in place before my change and remains
after it:
if CASPER_TESTS:
WEBPACK_FILE = 'webpack-stats-production.json'
else:
WEBPACK_FILE = os.path.join('var', 'webpack-stats-test.json')
I added similar logic in tools/webpack:
if "CASPER_TESTS" in os.environ:
build_for_prod_or_casper(args.quiet)
I also made the helper functions in `./tools/webpack` have
nicer names.
So, now tools should all be able to run standalone and not
rely on previous tools creating webpack stats files for
them and leaving them in the file system. That's good.
Things are still a bit janky, though. It's not completely
clear to me why `test-js-with-casper` should work off of
a different webpack configuration than the other tests.
For now most of the jankiness is around Casper, and we have
hacks in two different places, `zproject/test_settings.py` and
`tools/webpack` to force it to use the production stats
file instead of the "test" one, even though Casper uses
test-like settings for other things like which database
you're using.
2018-09-06 21:01:45 +02:00
|
|
|
build_for_prod_or_casper(args.quiet)
|