Cockpit Starter Kit
Scaffolding for a Cockpit module.
Getting and building the source
Make sure you have
npm available (usually from your distribution package).
These commands check out the source and build it into the
git clone https://github.com/cockpit-project/starter-kit.git cd starter-kit make
make install compiles and installs the package in
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/starter-kit
After changing the code and running
make again, reload the Cockpit page in
You can also use watch mode to automatically update the webpack on every code change with
$ npm run watch
$ make watch
Cockpit Starter Kit uses ESLint to automatically check
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
Running tests locally
make check to build an RPM, install it into a standard Cockpit test VM
(centos-8-stream 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
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-8-stream test/check-application -tvs
You can also run the test against a different Cockpit image, for example:
TEST_OS=fedora-34 make check
Running tests in CI
These tests can be run in Cirrus CI, on their free
Linux Containers environment which
/dev/kvm. Please see Quick
Start how to set up Cirrus CI for
your project after forking from starter-kit.
The included .cirrus.yml runs the integration tests for two operating systems (Fedora and CentOS 8). Note that if/once your project grows bigger, or gets frequent changes, you may need to move to a paid account, or different infrastructure with more capacity.
Tests also run in Packit for all currently supported Fedora releases; see the packit.yaml control file. You need to enable Packit-as-a-service in your GitHub project to use this. To run the tests in the exact same way for upstream pull requests and for Fedora package update gating, the tests are wrapped in the FMF metadata format for using with the tmt test management tool. Note that Packit tests can not run their own virtual machine images, thus they only run @nondestructive tests.
After cloning the Starter Kit you should rename the files, package names, and labels to your own project's name. Use these commands to find out what to change:
find -iname '*starter*' git grep -i starter
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 action that calls a set of release scripts.
It is important to keep your NPM modules up to date, to keep up with security updates and bug fixes. This is done with the npm-update bot script which is run weekly or upon manual request through the npm-update.yml GitHub action.