cockpit-certificates - GitLite

KO | EN

gitlite — search

#react #ai #android #machine-learning #deep-learning #docker #macos #java #awesome #cli #kubernetes #pytorch #mcp #openai

cockpit-certificates

(★ 65)

(IN PROGRESS) certificate management plugin for cockpit

파일 탐색기

최종 버전 다운로드 (.zip)

- container
- run
- version
- - cockpit-lib-update.yml
  - tasks-container-update.yml
- dependabot.yml.disabled
- cockpit-certificates.spec.in
- all.fmf
- app.jsx
- app.scss
- certificateActions.css
- certificateActions.jsx
- certificateList.jsx
- dbus.js
- emptyState.jsx
- helpers.js
- index.html
- index.js
- manifest.json
- requestCertificate.jsx
- states.js
- - browser.sh
  - main.fmf
  - run-test.sh
- check-application
- reference-image
- run
- vm.install
.eslintignore
.eslintrc.json
.gitignore
.stylelintrc.json
.tasks
build.js
HACKING.md
LICENSE
Makefile
org.cockpit-project.certificates.metainfo.xml
package.json
packit.yaml
pyproject.toml
README.md

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# cockpit-certificates

A certificate management plugin for [Cockpit](https://cockpit-project.org/)

# Technologies

- cockpit-certificates communicates with [certmonger](https://www.freeipa.org/page/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](https://esbuild.github.io/api/#watch) 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](https://eslint.org/) 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](https://packit.dev/) for all currently supported
Fedora releases; see the [packit.yaml](./packit.yaml) control file. You need to
[enable Packit-as-a-service](https://packit.dev/docs/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](https://docs.fedoraproject.org/en-US/ci/), the
tests are wrapped in the [FMF metadata format](https://github.com/psss/fmf)
for using with the [tmt test management tool](https://docs.fedoraproject.org/en-US/ci/tmt/).
Note that Packit tests can *not* run their own virtual machine images, thus
they only run [@nondestructive tests](https://github.com/cockpit-project/cockpit/blob/main/test/common/testlib.py).

# Automated maintenance

It is important to keep your [NPM modules](./package.json) up to date, to keep
up with security updates and bug fixes. This happens with
[dependabot](https://github.com/dependabot),
see [configuration file](.github/dependabot.yml).

# Running tests in CI
Tests run in [Packit](https://packit.dev/) for all currently supported
Fedora releases; see the [packit.yaml](./packit.yaml) control file. You need to
[enable Packit-as-a-service](https://packit.dev/docs/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](https://docs.fedoraproject.org/en-US/ci/), the
tests are wrapped in the [FMF metadata format](https://github.com/psss/fmf)
for using with the [tmt test management tool](https://docs.fedoraproject.org/en-US/ci/tmt/).
Note that Packit tests can *not* run their own virtual machine images, thus
they only run [@nondestructive tests](https://github.com/martinpitt/cockpit/blob/main/test/common/testlib.py).