Use yarn and webpack to manage zuul-web javascript
yarn drives package and dependency management. webpack handles
bundling, minification and transpiling down to browser-acceptable
javascript but allows for more modern javascript like import statements.
There are some really neat things in the webpack dev server. CSS
changes, for instance, get applied immediately without a refresh. Other
things, like the jquery plugin do need a refresh, but it's handled just
on a file changing.
As a followup, we can also consider turning the majority of the status page
into a webpack library that other people can depend on as a mechanism
for direct use. Things like that haven't been touched because allowing
folks to poke at the existing known status page without too many changes
using the tools seems like a good way for people to learn/understand the
stack.
Move things so that the built content gets put
into zuul/web/static so that the built-in static serving from zuul-web
will/can serve the files.
Update MANIFEST.in so that if npm run build:dist is run before the
python setup.py sdist, the built html/javascript content will be
included in the source tarball.
Add a pbr hook so that if yarn is installed, javascript content will be
built before the tarball.
Add a zuul job with a success url that contains a source_url
pointing to the live v3 data.
This adds a framework for verifying that we can serve the web app
urls and their dependencies for all of the various ways we want to
support folks hosting zuul-web.
It includes a very simple reverse proxy server for approximating
what we do in openstack to "white label" the Zuul service -- that
is, hide the multitenancy aspect and present the single tenant
at the site root.
We can run similar tests without the proxy to ensure the default,
multi-tenant view works as well.
Add babel transpiling enabling use of ES6 features
ECMAScript6 has a bunch of nice things, like block scoped variables,
const, template strings and classes. Babel is a javascript transpiler
which webpack can use to allow us to write using modern javascript but
the resulting code to still work on older browsers.
Use the babel-plugin-angularjs-annotate so that angular's dependency
injection doesn't get borked by babel's transpiling things (which causes
variables to otherwise be renamed in a way that causes angular to not
find them)
While we're at it, replace our use of var with let (let is the new
block-scoped version of var) and toss in some use of const and template
strings for good measure.
Add StandardJS eslint config for linting
JavaScript Standard Style is a code style similar to pep8/flake8. It's
being added here not because of the pep8 part, but because the pyflakes
equivalent can catch real errors. This uses the babel-eslint parser
since we're using Babel to transpile already.
This auto-formats the existing code with:
npm run format
Rather than using StandardJS directly through the 'standard' package,
use the standardjs eslint plugin so that we can ignore the camelCase
rule (and any other rule that might emerge in the future)
Many of under_score/camelCase were fixed in a previous version of the patch.
Since the prevailing zuul style is camelCase methods anyway, those fixes
were left. That warning has now been disabled.
Other things, such as == vs. === and ensuring template
strings are in backticks are fixed.
Ignore indentation errors for now - we'll fix them at the end of this
stack and then remove the exclusion.
Add a 'format' npm run target that will run the eslint command with
--fix for ease of fixing reported issues.
Add a 'lint' npm run target and a 'lint' environment that runs with
linting turned to errors. The next patch makes the lint environment more
broadly useful.
When we run lint, also run the BundleAnalyzerPlugin and set the
success-url to the report.
Add an angular controller for status and stream page
Wrap the status and stream page construction with an angular controller
so that all the javascripts can be bundled in a single file.
Building the files locally is wonderful and all, but what we really want
is to make a tarball that has the built code so that it can be deployed.
Put it in the root source dir so that it can be used with the zuul
fetch-javascript-tarball role.
Also, replace the custom npm job with the new build-javascript-content
job which naturally grabs the content we want.
Make a 'main.js' file that imports the other three so that we just have
a single bundle. Then, add a 'vendor' entry in the common webpack file
and use the CommonsChunkPlugin to extract dependencies into their own
bundle. A second CommonsChunkPlugin entry pulls out a little bit of
metadata that would otherwise cause the main and vendor chunks to change
even with no source change. Then add chunkhash into the filename. This
way the files themselves can be aggressively cached.
This all follows recommendations from https://webpack.js.org/guides/caching/
https://webpack.js.org/guides/code-splitting/ and
https://webpack.js.org/guides/output-management/
Change-Id: I2e1230783fe57f1bc3b7818460463df1e659936b
Co-Authored-By: Tristan Cacqueray <tdecacqu@redhat.com>
Co-Authored-By: James E. Blair <jeblair@redhat.com>
diff --git a/doc/source/developer/javascript.rst b/doc/source/developer/javascript.rst
new file mode 100644
index 0000000..9eca55e
--- /dev/null
+++ b/doc/source/developer/javascript.rst
@@ -0,0 +1,223 @@
+Zuul Web Javascript
+===================
+
+zuul-web has an html, css and javascript component that is managed
+using Javascript toolchains. It is intended to be served by zuul-web
+directly from zuul/web/static in the simple case, or to be published to
+an alternate static web location, such as an Apache server.
+
+The web applications are managed by `yarn`_ and `webpack`_ which in turn both
+assume a functioning and recent `nodejs`_ installation.
+
+For the impatient who don't want deal with javascript toolchains
+----------------------------------------------------------------
+
+tl;dr - You have to build stuff with javascript tools.
+
+The best thing would be to get familiar with the tools, there are a lot of
+good features available. But, if you don't want to know anything about the
+Javascript toolchains a few helpers have been provided.
+
+If you have npm and docker installed and don't want to install newer nodejs
+or a bunch of javascript libraries, you can run:
+
+.. code-block:: bash
+
+ npm run build:docker
+
+If you have docker but do not have npm or nodejs installed, you can build
+the web app with:
+
+.. code-block:: bash
+
+ docker run -it --rm -v $(PWD):/usr/src/app -w /usr/src/app node:alpine \
+ npm run build:dist-with-depends
+
+Both do the same thing. Both versions will result in the built files being
+put into ``zuul/web/static``.
+
+.. note:: Because the user inside of the Docker container is root, the files
+ that it emits into zuul/web/static will be owned by root.
+
+yarn dependency management
+--------------------------
+
+`yarn`_ manages the javascript dependencies. That means the first step is
+getting `yarn`_ installed.
+
+.. code-block:: bash
+
+ tools/install-js-tools.sh
+
+The ``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
+``tools/install-js-repos-rpm.sh``.
+
+Once yarn is installed, getting dependencies installed is:
+
+.. code-block:: bash
+
+ yarn install
+
+The ``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:
+
+.. code-block:: bash
+
+ yarn add awesome-package
+
+To remove dependencies:
+
+.. code-block:: bash
+
+ yarn remove terrible-package
+
+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:
+
+.. code-block:: bash
+
+ yarn add awesome-package
+
+Dependencies are installed into the ``node_modules`` directory. Deleting that
+directory and re-running ``yarn install`` should always be safe.
+
+webpack asset management
+------------------------
+
+`webpack`_ takes care of bundling web assets for deployment, including tasks
+such as minifying and transpiling for older browsers. It takes a
+javascript-first approach, and generates a html file that includes the
+appropriate javascript and CSS to get going.
+
+We need to modify the html generated for each of our pages, so there are
+templates in ``web/templates``.
+
+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.dev.js`` or ``web/config/webpack.prod.js``. Most of the
+important bits are in ``web/config/webpack.common.js``.
+
+Development
+-----------
+
+Building the code can be done with:
+
+.. code-block:: bash
+
+ npm run build
+
+zuul-web has a ``static`` route defined which serves files from
+``zuul/web/static``. ``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:
+
+.. code-block:: bash
+
+ npm run build:dev
+
+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:
+
+.. code-block:: bash
+
+ npm run start
+
+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:
+
+.. code-block:: bash
+
+ npm run start -- --open-file='static/status.html'
+
+That's kind of annoying though, so additional targets exist for common tasks:
+
+Run status against `basic` built-in demo data.
+
+.. code-block:: bash
+
+ npm run start:status:basic
+
+Run status against `openstack` built-in demo data
+
+.. code-block:: bash
+
+ npm run start:status:openstack
+
+Run status against `tree` built-in demo data.
+
+.. code-block:: bash
+
+ npm run start:status:tree
+
+Run status against live data from OpenStack's Zuul.
+
+.. code-block:: bash
+
+ npm run start:status
+
+Run builds against live data from OpenStack's Zuul.
+
+.. code-block:: bash
+
+ npm run start:builds
+
+Run jobs against live data from OpenStack's Zuul.
+
+.. code-block:: bash
+
+ npm run start:jobs
+
+Run console streamer.
+
+.. note:: There is not currently a good way to pass build_id paramter.
+
+.. code-block:: bash
+
+ npm run start:stream
+
+Additional run commands can be added in `package.json` in the ``scripts``
+section.
+
+Deploying
+---------
+
+The web application is a set of static files and is designed to be served
+by zuul-web from its ``static`` route. In order to make sure this works
+properly, the javascript build needs to be performed so that the javascript
+files are in the ``zuul/web/static`` directory. Because the javascript
+build outputs into the ``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.
+
+Debugging minified code
+-----------------------
+
+Both the ``dev`` and ``prod`` ennvironments use the same `devtool`_
+called ``source-map`` which makes debugging errors easier by including mapping
+information from the minified and bundled resources to their approriate
+non-minified source code locations. Javascript errors in the browser as seen
+in the developer console can be clicked on and the appropriate actual source
+code location will be shown.
+
+``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.
+
+.. _yarn: https://yarnpkg.com/en/
+.. _nodejs: https://nodejs.org/
+.. _webpack: https://webpack.js.org/
+.. _devtool: https://webpack.js.org/configuration/devtool/#devtool