If you have docker but do not have npm or nodejs installed, you can build the web app with:
Both do the same thing. Both versions will result in the built files being put into
Because the user inside of the Docker container is root, the files that it emits into zuul/web/static will be owned by root.
tools/install-js-tools.sh script will add apt or yum repositories and install nodejs and yarn from them. For RPM-based distros it needs to know which repo description file to download, so it calls out to
Once yarn is installed, getting dependencies installed is:
yarn.lock file contains all of the specific versions that were installed before. Since this is an application it has been added to the repo.
To add new dependencies:
To remove dependencies:
Adding or removing packages will add the logical dependency to
package.json and will record the version of the package and any of its dependencies that were installed into
yarn.lock so that other users can simply run
yarn install and get the same environment.
To update a dependency:
Dependencies are installed into the
node_modules directory. Deleting that directory and re-running
yarn install should always be safe.
We need to modify the html generated for each of our pages, so there are templates in
The main webpack config file is
webpack.config.js. In the Zuul tree that file is a stub file that includes either a dev or a prod environment from
web/config/webpack.prod.js. Most of the important bits are in
Building the code can be done with:
zuul-web has a
static route defined which serves files from
npm run build will put the build output files into the
zuul/web/static directory so that zuul-web can serve them.
There is a also a development-oriented version of that same command:
which will build for the
dev environment. This causes some sample data to be bundled and included.
Webpack includes a development server that handles things like reloading and hot-updating of code. The following:
will build the code and launch the dev server on localhost:8080. It will additionally watch for changes to the files and re-compile/refresh as needed. Arbitrary command line options will be passed through after a
-- such as:
That's kind of annoying though, so additional targets exist for common tasks:
Run status against basic built-in demo data.
Run status against openstack built-in demo data
Run status against tree built-in demo data.
Run status against live data from OpenStack's Zuul.
Run builds against live data from OpenStack's Zuul.
Run jobs against live data from OpenStack's Zuul.
Run console streamer.
There is not currently a good way to pass build_id paramter.
Additional run commands can be added in package.json in the
The web application is a set of static files and is designed to be served by zuul-web from its
zuul/web/static directory, as long as
npm run build has been done before
pip install . or
python setup.py sdist, all the files will be where they need to be.
prod ennvironments use the same devtool called
source-map is considered an appropriate devtool for production, but has the downside that it is slower to update. However, since it includes the most complete mapping information and doesn't impact execution performance, so in our case we use it for both.