This hasn't kept up in the last years, and was now grossly wrong.
cockpit.service just runs `cockpit-tls` which does not use glib. But
Running it as root is dangerous and also not at all helpful for
debugging!
Default to logging all debug messages, and drop the obsolete
"cockpit-bridge" log domain.
Refine the restarting of cockpit.service to just stopping it. Socket
activation will do the rest.
Refer to debug logging of the bridge.
We didn't showcase this anywhere and it was kinda just a "if you know
you know" kinda feature, or you looked into the blog post generation
script or release process docs. But for contributors there wasn't a good
way to add a release note when wanted and instead it became a thing we
added when we wanted to.
With this we now also tell the contributors how to add release notes if
they want to, but it is not mandatory for contributions.
Fixes: https://github.com/cockpit-project/cockpit/issues/22485
Signed-off-by: Freya Gustavsson <freya@venefilyn.se>
Bind mount the whole dist directory. Rebuilding bundles with esbuild
removes and recreates the subdirectories, so that existing bind mounts
will go into the void.
It conceptually fits better there, as it's shared by all external
projects. That makes importing easier as it doesn't have to be
enumerated separately in COCKPIT_REPO_FILES any more.
Now that we don't install any suid root stuff any more and use fully
dynamic system users, we can build our git tree straight into a
systemd-sysext [1]. With that we can test all parts of cockpit
(including tls, ws, session, bridge, the login page, and systemd units)
in a safe manner on the host system. Nothing ever hits the disk (it's
installed to /run/extensions) and allows fast iteration.
This is primarily aimed at our documented development workflow of
building in a cockpit/tasks toolbox, but written in a generic way so
that it should work on Fedora, CentOS/RHEL, Debian/Ubuntu, and Arch, and
also directly from the host system. Use the "extension-release"
declaration to ensure compatibility between the build and host systems.
[1] https://www.freedesktop.org/software/systemd/man/latest/systemd-sysext.htmlhttps://issues.redhat.com/browse/COCKPIT-1208
The "Working on the non-web parts of Cockpit" section is mostly
concerned about running the unit tests, with a little bit of how to
build the source tree. Rename it, to disambiguate it from the later
"Working on your local machine" section.
The Python bridge is the one and only since commit 7c7ab45e3f. Stop
talking about it as an alternative.
Explain what the bridge actually does in high-level terms, to convey an
initial architectural understanding.
Make the session pages section easier to follow by telling the user to build the pages before giving the address to see the changes. Also, divide the section with subheaders to make it more ovbious to install the Cockpit server before trying to build and connect.
Signed-off-by: Ashley Cui <acui@redhat.com>
You can now do something like this:
$ pytest -k test_browser --js-cov-files='*/fsinfo.ts'
and get results like this:
pkg/lib/cockpit/fsinfo.ts:33:49-33:63 json_merge
▼ from here
33 const updated = is_json_dict(current) ? { ...current } : { };
▲ to here
pkg/lib/cockpit/fsinfo.ts:36:33-38:14 json_merge
▼ from here
36 if (value === null) {
37 delete updated[key];
38 } else {
▲ to here
Since we also use the same approach for collecting data for integration
tests (Profiler.takePreciseCoverage), we could easily add support there
as well.
QUnit tests are no longer driven by automake (and haven't been for a
long time) so adjust the hints about how to run individual tests to
mention pytest.
Similar to what commit c9ac6736b3 did for stylelint, move
ESLint to static code checks as well. It already runs from there (and
actually correctly since the previous commit).
stylelint 16 causes a deadlock/crash in esbuild [1]. There's no movement
on that issue, and we want stylelint 16 to be able to support the
Browser Baseline 2023.
So let's give up, and untangle stylelint from esbuild. We can just as
well call it from our static code checks. The main developer regression
is that the feedback cycle is faster in build.js watch mode than calling
test/static-code, but these days with IDE integration (like ALE) that
should hopefully not matter that much.
As we use `git ls-files` now, this also starts to cover files in doc/
and test/. Ignore the former for now, let's fix these separately.
[1] https://github.com/evanw/esbuild/issues/3542
New contributors keep trying this and fail, this has become a FAQ.
Explicitly point out that the given clone command is not an accident,
but deliberate, and show how to work with a fork.
starter-kit and derivatives don't understand the build.js `-r` option,
only the environment variable. So properly handle the latter, and update
the documentation to use the env variable, to get a common workflow for
all our projects.
Also fix the destination path, the rsync plugin moved to
/usr/local/share/cockpit some time ago.
Commit 18576f7d18 moved them to /qunit. Adjust the pytest wrapper,
documentation and example accordingly. This brings back the HTML tests
in the pytest unit test run.
We don't need the `$ESLINT`/`$STYLELINT` env variables any more to
coordinate between build.js and webpack-config.js, as everything is in
build.js now. Update HACKING.md accordingly.
Implement our own watch mode due to the deficiencies of esbuild's [1].
This is similar to podman's [2], but with recursive watching.
Because the approach for redefining breakpoints changed, update pixel
tests for the spacing noise.
Co-Authored-By: Martin Pitt <mpitt@redhat.com>
Fixes#17629
[1] https://github.com/evanw/esbuild/issues/1204#issuecomment-1482909251
[2] https://github.com/cockpit-project/cockpit-podman/pull/1243
This is our primary and only interaction point with building bundles, so it
should be in the top-level directory. Also, we are going to switch to esbuild
soon, so naming it "webpack" will be confusing. Move it to ./build.js like
cockpit-podman already did.
Keep tools/webpack-{make.js,watch} as a shell shim for a little while, which
points to the new tool and the documentation.
This supports the "only work on web-y bits without autotools" workflow.
It avoids having to run `node-modules checkout` as a user from a clean
tree, and also helps after pulling new commits which change
node_modules.
As `argparse`, `webpack`, and our rsync plugin all live in node_modules,
to convert these to dynamic imports.
Now that our webpack config can build all webpacks in one go,
webpack-make.js does not require the directory any more. We want to make
tools/webpack-make.js the one true entry point, as this is also
compatible to the future esbuild conversion (where we can't run the
esbuild binary directly). Rename the `prefix` argument name to `onlydir`
to match the env variable.
This also allows us to use watch mode for all pages simultaneously. This
is still a lot slower than building a single page only, so until we
switch to esbuild, document both approaches.
In pkg/build, go back to calling tools/webpack-make.js.
Most contributors want to work on the web (HTML/JavaScript) parts of
Cockpit. For that it's not necessary to deal with autogen.sh, make,
etc., as that's really slow and irrelevant.
Thus move the webpack-watch part to the top, and stop treating it as
alternative workflow: It's the primary and recommended way to develop the
session pages. Don't make new contributors suffer through building things with
`make`.
A lot of newcomers have been struggling with installing a lot of
packages on their distribution (especially Ubuntu). This is also really
not what they should do, as it clutters desktops with a lot of
development dependencies, and then it's still hard to get something
actually working.
Recommend running our cockpit/tasks container in toolbox or distrobox.
This works fine on Fedora, CentOS, RHEL, and Ubuntu, is much easier, safer, and
gives reproducible results.
Move the manual installation of development dependencies to the very end, and
trim and update it a bit.
Fixes#18460
These are annoying, as they break the "copy" button in GitHub's markdown
view and convenient "select and copy line". These commands are already
formatted as code.
It is sometimes necessary to enable more than one debug target, e.g.
`dbus` and `services`. But `all` is too much of a firehose.
Check window.debugging for a substring instead of equality, similar to
what the Services page did in commit 0d6166b174.
The official way to invoke the python bridge is now via python3 -m.
We'll bring back a .pyz as an implementation detail of our remote
injection system in the near future.
Add a new testcase in test/pytest/test_server.py which knows how to run
the QUnit tests, including collection of coverage information.
Make sure we build the `test-server` and the webpacks before running
`pytest` from the Makefile. For running `pytest` directly, the html
tests will be skipped if the test-server is missing or if there are no
`dist/*/test-*.html` files.
Remove the `make pycheck` target, and drop the extra scenario from the
unit-tests workflow.
`pytest` now takes significantly longer to run. The pytest-xdist
plugin can help with this, and it works in combination with our other
plugins, pytest-timeout and pytest-cov.
For manual invocation of pytest, use something like the following:
pytest -n auto --cov --timeout 30
We run the tests non-parallel in the unit-tests container because
there's no real advantage to speeding this up in that case, and running
in parallel makes the log output more difficult to read.
