(Old) Wireframe design:
-
CPU utilization:
dd if=/dev/urandom of=/dev/null bs=1M count=10000
-
CPU saturation (high load):
for i in `seq 10000`; do dd if=/dev/urandom of=/dev/null bs=1M count=5 & done
-
Memory utilization/saturation:
MEMBLOB=$(yes | dd bs=1M count=500 iflag=fullblock)
-
Disk utilization:
find /usr -type f | xargs cat >/dev/null
-
Network utilization:
dd if=/dev/zero bs=1M count=2000 | ssh admin@c 'cat >/dev/null'
Make sure you have npm
available (usually from your distribution package).
These commands check out the source and build it into the dist/
directory:
git clone https://github.com/martinpitt/performance-graphs
cd performance-graphs
make
make install
compiles and installs the package in /usr/share/cockpit/
. The
convenience targets srpm
and rpm
build the source and binary rpms,
respectively. Both of these make use of the dist-gzip
target, which is used
to generate the distribution tarball. In production
mode, source files are
automatically minified and compressed. Set NODE_ENV=production
if you want to
duplicate this behavior.
For development, you usually want to run your module straight out of the git
tree. To do that, link that to the location were cockpit-bridge
looks for packages:
mkdir -p ~/.local/share/cockpit
ln -s `pwd`/dist ~/.local/share/cockpit/performance-graphs
After changing the code and running make
again, reload the Cockpit page in
your browser.
You can also use watch mode to automatically update the webpack on every code change with
$ npm run watch
or
$ make watch
Cockpit Starter Kit uses ESLint to automatically check
JavaScript code style in .js
and .jsx
files.
The linter is executed within every build as a webpack preloader.
For developer convenience, the ESLint can be started explicitly by:
$ npm run eslint
Violations of some rules can be fixed automatically by:
$ npm run eslint:fix
Rules configuration can be found in the .eslintrc.json
file.
Run make check
to build an RPM, install it into a standard Cockpit test VM
(centos-7 by default), and run the test/check-application integration test on
it. This uses Cockpit's Chrome DevTools Protocol based browser tests, through a
Python API abstraction. Note that this API is not guaranteed to be stable, so
if you run into failures and don't want to adjust tests, consider checking out
Cockpit's test/common from a tag instead of master (see the test/common
target in Makefile
).
After the test VM is prepared, you can manually run the test without rebuilding the VM, possibly with extra options for tracing and halting on test failures (for interactive debugging):
TEST_OS=centos-7 test/check-application -tvs
You can also run the test against a different Cockpit image, for example:
TEST_OS=fedora-32 make check
Once your cloned project is ready for a release, you should consider automating that. Cockpituous release aims to fully automate project releases to GitHub, Fedora, Ubuntu, COPR, Docker Hub, and other places. The intention is that the only manual step for releasing a project is to create a signed tag for the version number; pushing the tag then triggers a GitHub webhook that calls a set of release scripts (on Cockpit's CI infrastructure).
starter-kit includes an example cockpitous release script that builds an upstream release tarball and source RPM. Please see the above cockpituous documentation for details.
- The Starter Kit announcement blog post explains the rationale for this project.
- Cockpit Deployment and Developer documentation
- Make your project easily discoverable