Skip to content

Cockpit component for managing software updates for OSTree based systems

License

Notifications You must be signed in to change notification settings

cockpit-project/cockpit-ostree

Repository files navigation

cockpit-ostree

Cockpit page for managing software updates for OSTree based systems.

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/cockpit-project/cockpit-ostree.git
cd cockpit-ostree
make

Installing

make install compiles and installs the package in /usr/local/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, link that to the location were cockpit-bridge looks for packages:

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

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

Running eslint

Cockpit uses ESLint to automatically check JavaScript code style in .js and .jsx files.

eslint is executed as part of test/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.

Running stylelint

Cockpit uses Stylelint to automatically check CSS code style in .css and scss files.

styleint is executed as part of test/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.

Automated Testing

Run make check to build an RPM, install it into a standard Cockpit test VM (fedora-coreos by default), and run the test/check-ostree 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=fedora-coreos test/check-ostree -tvs

Automated release

The intention is that the only manual step for releasing a project is to create a signed tag for the version number, which includes a summary of the noteworthy changes:

123

- this new feature
- fix bug #123

Pushing the release tag triggers the release.yml GitHub action workflow. This creates the official release tarball and publishes as upstream release to GitHub.

The Fedora and COPR releases are done with Packit, see the packit.yaml control file.

Automated maintenance

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.

Further reading