Repository files navigation

Cockpit module for reading/displaying Dell iDRAC system information and metrics

On Debian/Ubuntu:

sudo apt install gettext nodejs npm make

On Fedora:

sudo dnf install gettext nodejs npm make

These commands check out the source and build it into thedist/ directory:

git clone https://github.com/cockpit-project/starter-kit.gitcd starter-kitmake

make install compiles and installs the package in/usr/local/share/cockpit/. Theconvenience targetssrpm andrpm build the source and binary rpms,respectively. Both of these make use of thedist target, which is usedto generate the distribution tarball. Inproduction mode, source files areautomatically minified and compressed. SetNODE_ENV=production if you want toduplicate this behavior.

For development, you usually want to run your module straight out of the gittree. To do that, runmake devel-install, which links your checkout to thelocation were cockpit-bridge looks for packages. If you prefer to dothis manually:

mkdir -p ~/.local/share/cockpitln -s `pwd`/dist ~/.local/share/cockpit/starter-kit

After changing the code and runningmake again, reload the Cockpit page inyour browser.

You can also usewatch mode toautomatically update the bundle on every code change with

./build.js -w

or

make watch

When developing against a virtual machine, watch mode can also automatically uploadthe code changes by setting theRSYNC environment variable tothe remote hostname.

RSYNC=c make watch

When developing against a remote host as a normal user,RSYNC_DEVEL can beset to upload code changes to~/.local/share/cockpit/ instead of/usr/local.

RSYNC_DEVEL=example.com make watch

To "uninstall" the locally installed version, runmake devel-uninstall, orremove manually the symlink:

rm ~/.local/share/cockpit/starter-kit

Cockpit Starter Kit usesESLint to automatically checkJavaScript/TypeScript code style in.js[x] and.ts[x] files.

eslint is executed as part oftest/static-code, aka.make codecheck.

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.

Cockpit usesStylelint to automatically check CSS codestyle in.css andscss files.

styleint is executed as part oftest/static-code, aka.make codecheck.

For developer convenience, the Stylelint can be started explicitly by:

npm run stylelint

Violations of some rules can be fixed automatically by:

npm run stylelint:fix

Rules configuration can be found in the.stylelintrc.json file.

Runmake check to build an RPM, install it into a standard Cockpit test VM(centos-9-stream by default), and run the test/check-application integration test onit. This uses Cockpit's Chrome DevTools Protocol based browser tests, through aPython API abstraction. Note that this API is not guaranteed to be stable, soif you run into failures and don't want to adjust tests, consider checking outCockpit's test/common from a tag instead of main (see thetest/commontarget inMakefile).

After the test VM is prepared, you can manually run the test without rebuildingthe VM, possibly with extra options for tracing and halting on test failures(for interactive debugging):

TEST_OS=centos-9-stream test/check-application -tvs

It is possible to setup the test environment without running the tests:

TEST_OS=centos-9-stream make prepare-check

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

TEST_OS=fedora-40 make check

These tests can be run inCirrus CI, on their freeLinux Containers environment whichexplicitly supports/dev/kvm. Please seeQuickStart how to set up Cirrus CI foryour project after forking from starter-kit.

The included.cirrus.yml runs the integration tests for twooperating systems (Fedora and CentOS 8). Note that if/once your project growsbigger, or gets frequent changes, you may need to move to a paid account, ordifferent infrastructure with more capacity.

Tests also run inPackit for all currently supportedFedora releases; see thepackit.yaml control file. You need toenable 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 forFedora package update gating, thetests are wrapped in theFMF metadata formatfor using with thetmt test management tool.Note that Packit tests cannot run their own virtual machine images, thusthey only run@nondestructive tests.

After cloning the Starter Kit you should rename the files, package names, andlabels to your own project's name. Use these commands to find out what tochange:

find -iname '*starter*'git grep -i starter

Once your cloned project is ready for a release, you should consider automatingthat. The intention is that the only manual step for releasing a project is to createa signed tag for the version number, which includes a summary of the noteworthychanges:

123- this new feature- fix bug #123

Pushing the release tag triggers therelease.ymlGitHub action workflow. This creates theofficial release tarball and publishes as upstream release to GitHub. Theworkflow is disabled by default -- to use it, edit the file as per the commentat the top, and rename it to just*.yml.

The Fedora and COPR releases are done withPackit,see thepackit.yaml control file.

It is important to keep yourNPM modules up to date, to keepup with security updates and bug fixes. This happens withdependabot,seeconfiguration file.

• TheStarter Kit announcementblog post explains the rationale for this project.
• Cockpit Deployment and Developer documentation
• Make your project easily discoverable