cockpit-certificates

A certificate management plugin for Cockpit

Technologies

• cockpit-certificates communicates with certmonger through its D-Bus API.

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 https://github.com/skobyda/cockpit-certificates.git
cd cockpit-certificates
make

Installing

sudo 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 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, run make devel-install, which links your checkout to the location were cockpit-bridge looks for packages. If you prefer to do this manually:

mkdir -p ~/.local/share/cockpit
ln -s `pwd`/dist ~/.local/share/cockpit/cockpit-certificates

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 bundle on every code change with

$ npm run watch

or

$ make watch

When developing against a virtual machine, watch mode can also automatically upload the code changes by setting the RSYNC environment variable to the remote hostname.

$ RSYNC=c make watch

To "uninstall" the locally installed version, run make devel-uninstall, or remove manually the symlink:

rm ~/.local/share/cockpit/cockpit-certificates

Running eslint

cockpit-certificates uses ESLint to automatically check JavaScript code style in .js and .jsx files.

eslint is executed within every build.

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.

Running tests locally

Run 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 main (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-8-stream test/check-application -tvs

You can also run the test against a different Cockpit image, for example:

TEST_OS=fedora-testing make check

Running tests in CI

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.

Automated maintenance

It is important to keep your NPM modules up to date, to keep up with security updates and bug fixes. This happens with dependabot, see configuration file.

Running tests in CI

Tests 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.