Commit Graph

18 Commits

Author SHA1 Message Date
Jeremy Stanley 90d7dcb1ed Update unit test container setup and instructions
Update the TESTING.rst file to reflect that just installing and
starting zookeeperd is no longer sufficient now that we require TLS
and auth for the connection, as well as running database servers.
Suggest the container-based setup script instead. Also improve that
script to allow it to be invoked as a normal user, with root command
escalation tool choice (e.g. "sudo") supplied through a ROOTCMD
environment variable, so that things created inside the git worktree
like the CA don't end up root-owned.

Related, the tox-docker plugin previously suggested in the document
is no longer a viable option for the same reasons, so clean up the
plumbing for it in tox.ini as well.

Change-Id: Iac32799425a5bd4b1bdbf56f34a2310241ac4499
2022-08-05 21:00:02 +00:00
Antoine Musso 1903340017 Docs: fix stestr run example
In TESTING.rst, the `stestr run` incorrectly used `-t` to pass a test
filter. The option is common to `stestr` and is used to specify the test
path used for unittest discovery. It is already configured in
`.stestr.conf`:

  [DEFAULT]
  test_path=tests/unit

One just has to pass the fully qualified test name as an argument.

Change-Id: I8086ba862e5140eb2e1134c96359f1f30032b198
2020-01-21 10:36:07 +01:00
Stephen Finucane 390f071563 tox: Integrate tox-docker
This allows us to start a zookeeper instance via docker as part of the
standard tox process, avoiding issues like those described in [1]. It's
exposed as a separate target, to ensure users can use local
installations if necessary. This requires bumping the minimum version of
tox to 3.2 so we can make use of the 'requires' config option [2].

[1] https://review.openstack.org/#/c/648399/
[2] https://tox.readthedocs.io/en/latest/config.html#conf-requires

Change-Id: Ie848d409533b2a53523cd930299acf21ac10e13c
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
2019-04-03 15:05:42 +01:00
Tristan Cacqueray 68d1189871
Revert "Revert "web: rewrite interface in react""
This reverts commit 3dba813c64.

Change-Id: I233797a9b4e3485491c49675da2c2efbdba59449
2018-10-06 10:42:31 -05:00
James E. Blair 3dba813c64 Revert "web: rewrite interface in react"
Revert "Fix publish-openstack-javascript-content"

This reverts commit ca199eb9db.
This reverts commit 1082faae95.

This appears to remove the tarball publishing system that we rely on.

Change-Id: Id746fb826dfc01b157c5b772adc1d2991ddcd93a
2018-09-29 11:51:43 -07:00
Tristan Cacqueray 1082faae95 web: rewrite interface in react
This change rewrites the web interface using React:
http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-August/000528.html

Depends-On: https://review.openstack.org/591964
Change-Id: Ic6c33102ac3da69ebd0b8e9c6c8b431d51f3cfd4
Co-Authored-By: Monty Taylor <mordred@inaugust.com>
Co-Authored-By: James E. Blair <jeblair@redhat.com>
2018-09-27 02:14:46 +00:00
James E. Blair ef23bd4862 Revert "Revert "Switch to stestr""
This reverts commit e56801f2e8.

Change-Id: Icbea5ddd744d1fa65a397fb613731315687f9803
2018-05-17 08:33:40 -07:00
Tobias Henkel 082e7ec795 Update test instructions
We should update the test instructions a bit. This updates the py27
references to py35. Further when running a test in the foreground we
need to activate the virtualenv now. Otherwise ansible tests won't
work due because the wrong ansible or no ansible at all is found.

Change-Id: I96e8a21c93c87cfc1778ae07c54c4a19070a20da
2018-04-18 16:12:55 +02:00
James E. Blair e56801f2e8 Revert "Switch to stestr"
There are several differences between this and testr which we
need to discuss.  Let's wait until after the v3 release so we
don't delay it further.

This reverts commit 68e02466ce.

Change-Id: I873145c15fd88fe752cb987d0892c146c35041d8
2018-03-21 07:50:08 -07:00
Monty Taylor 68e02466ce
Switch to stestr
stestr is actively maintained. OpenStack is migrating to stestr,
go ahead and follow suit.

As part of this, shift the default values for STDOUT capture into the
tox.ini file. This preserves the current behavior of tox doing
capture and running tests directly not capturing.

Remove the depend on python-subunit... stestr takes care of that for us.

Change-Id: I90ae343a5db966f74e888bb98aab0bf39dcdd2cb
2018-03-18 10:41:40 -05:00
Monty Taylor 4a781a7f86
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>
2018-03-04 07:20:40 -06:00
Paul Belanger 174a8274d0 Rename zuul-launcher to zuul-executor
To avoid confusion with nodepool-launcher, we've decided to rename
zuul-launcher to zuul-executor.

Change-Id: I7d03cf0f0093400f4ba2e4beb1c92694224a3e8c
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
2017-03-15 12:21:24 -04:00
Jenkins 09bd3a4b23 Merge "Update testing doc to reflect unit subdir move" into feature/zuulv3 2017-03-03 18:09:18 +00:00
Jesse Keating b233e56e32 Update testing doc to reflect unit subdir move
Change-Id: I38babbafee2ba4d3e92481424041e5ff3bd9385c
2017-03-02 17:24:20 -08:00
Jesse Keating da819539b6 Document needing zookeeper to run tests
Change-Id: Idf796844263097ec1543654c3f5a201060b3e4e8
2017-03-01 13:17:59 -08:00
James E. Blair 6c358e72ea Support multiple triggers
Add the ability for Zuul to accept inputs from multiple trigger
sources simultaneously.

Pipelines are associated with exactly one trigger, which must now
be named in the configuration file.

Co-Authored-By: Monty Taylor <mordred@inaugust.com>

Change-Id: Ief2b31a7b8d85d30817f2747c1e2635f71ea24b9
2013-08-01 11:56:52 -07:00
James E. Blair dda6c91ef8 Use the public gear API to iterate over jobs in the queue
Also, add some more info about testing.

Change-Id: I2029a03d2ab017d826b01dc0b802c6e0e0328204
2013-07-29 14:12:12 -07:00
James E. Blair 9ab86621c8 Add TESTING file
Change-Id: Ifa3ff45189b794dfb2c29e127599dbe547b57f71
Reviewed-on: https://review.openstack.org/35354
Reviewed-by: Anita Kuno <anteaya@anteaya.info>
Reviewed-by: Jeremy Stanley <fungi@yuggoth.org>
Reviewed-by: Clark Boylan <clark.boylan@gmail.com>
Approved: James E. Blair <corvus@inaugust.com>
Tested-by: Jenkins
2013-07-06 18:24:10 +00:00