Skip to content
Everything you need to develop, test and deploy your own cockpit plugin
JavaScript Makefile Python HTML Shell CSS
Branch: master
Clone or download
martinpitt Add eslint rules for React hooks
These make components with simple state (only a few variables) easier to
read and maintain. See for
details. Hook are available since React 16.8, and we already depend on 16.10.

We can't use hooks in our actual code, as our only `Application`
component needs a constructor. But this enables the ESLint plugin to
guide developers to the right path if they use hooks.

Closes #239
Latest commit 024b1a2 Oct 16, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
po Properly initialize state of Application Aug 28, 2018
src Update babel to 7.5, and actually enable polyfills Jul 17, 2019
.eslintignore Add more sample content to subscriptions page Jul 26, 2017
.eslintrc.json Add eslint rules for React hooks Oct 18, 2019
.gitignore Add git tag derived version to tarball and spec Jun 22, 2018
.tasks tasks: Drop issue-scan Jul 11, 2019
.travis.yml Add .travis.yml (#15) Oct 19, 2017
LICENSE Initial commit with a LICENSE and README Jun 14, 2017
Makefile Support CI testing against a bots project PR Oct 2, 2019 Rename *.es6 to *.js Jul 17, 2019
Vagrantfile vagrant: Use rsync backend for file sharing Jun 25, 2018 Drop source map Jul 17, 2019
cockpituous-release cockpituous: Fix srpm Release: Jun 12, 2019
package.json Add eslint rules for React hooks Oct 18, 2019
webpack.config.js Rename *.es6 to *.js Jul 17, 2019

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 dist/ directory:

git clone
cd starter-kit


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/starter-kit

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


$ make watch

Running eslint

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.

Automated Testing

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-28 make check


This directory contains a Vagrantfile that installs and starts cockpit on a Fedora 26 cloud image. Run vagrant up to start it and vagrant rsync to synchronize the dist directory to /usr/local/share/cockit/starter-kit. Use vagrant rsync-auto to automatically sync when contents of the dist directory change.


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

Automated release

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.

Further reading

You can’t perform that action at this time.