Making test-functions strict required some test adjustments where we
incorrectly expected an number while we receive in fact a string. As
getAttribute() returns either a string or null.
Differential ShellCheck / shellcheck (push) Waiting to run
Cockpit manifests / validate-manifests (push) Waiting to run
Cockpit manifests / validate-schemas (push) Waiting to run
This got removed from the template with e51cf81cd2 ("unit tests: Don't
load cockpit.js in the qunit HTML template") but we've been deadcode
expanding it ever since. Drop it.
This plugin assumes that the 'po' directory is located at `$SRCDIR/po`
or `./po` if `$SRCDIR` is unset. That conflicts with our desire to be
able to run `build.js` from other directories and is also a little bit
"evil" in terms of hardcoding information about project layout.
Add an optional `podir` option to the plugin which should be set to the
`po/` path. Set it from `build.js` for Cockpit itself. For other users
of the plugin, we preserve the fallback of using `$SRCDIR/po` or `./po`
so that we don't break them on the next cockpitlib upgrade. The
expectation is that everyone will migrate to providing the `podir`
option, however.
Since 15469bb469 ("tools: Teach webpack-make.js to get node_modules by
itself") we want to support people invoking `./build.js` without having
run `tools/node-modules checkout`. This commit added an invocation of
`tools/node-modules` to make sure that everything is checked out and up
to date.
Unfortunately, `file.js` gets imported before that happens, and since
7cab667c1b ("pkg: Change to variable font") this module import isn't
pure: it tries to read the font information from the `node_modules`
directory at import time, before we've run the update. That means that
we can either:
- fail completely, if the `node_modules` aren't checked out yet
- (maybe worse): read stale information if they're checked out, but to
the incorrect version (and get updated in between the read and the
build)
Move the top-level computation added in that commit to `getFiles()`
which gets called — once — at runtime, after we've done the update. We
need to rename a local to avoid a shadow. Move related constants, some
comments, and a few other "computationy" things (like path computations)
which are no longer needed at the toplevel into the function as well.
`all_subdirs` is left at the toplevel because it's entirely based on
internal data and it's an export (and used from build.js).
This module is now side-effect-free on import and the automatic
`node_modules` checkout functionality is working properly again.
It's now possible to run build.js from any directory. Demonstrate that
by removing the `cd` that we've been depending on to make it work. Use
the new `-o` option to direct the output to the srcdir instead. That
means that this commit changes absolutely nothing, but it's still
important: it demonstrates that the out-of-srcdir invocation works (and
tests that it will continue to work).
In the future we hope to remove 'dist/' from the tarballs, which means
that it will be a purely built artifact, changing the logic of which
directory it belongs in. At that point we can simply drop the '-o'
option and let it land in the default location, the `builddir`.
Add a -o option (default to `.`) for where to send the output. It will
still be split into `dist/` and `qunit/` subdirectories, but relative to
the given path instead of assuming it goes in the cwd.
Make sure we send `metafile.json` and `runtime-npm-modules.txt` to the
output directory as well.
Between `build.js` and `file.js` we determine the location of `pkg` (and
various tools that we need to invoke) in one of two ways, neither of
them particularly good:
- they're assumed to be relative to '.', which only works if ./build.js
is invoked from the automake srcdir. That happens to be the case
when pkg/Makefile.am does the invocation (it does a 'cd' first) but
it breaks if you try to run build.js manually from a different
directory.
- redundantly, if `$SRCDIR` is set, this will be used in some (but not
all) places
Let's standardize on looking at `import.meta.dirname`. This is how node
resolves imports, so it's pretty much guaranteed to be correct (or else
the script itself wouldn't be running in the first place). This is
an absolute pathname derived from argv[1] as passed to node (ie:
build.js itself).
For the qunit plugin, `import.meta.dirname` is the path of the plugin
itself, which makes it perfect for finding the `.template.html.in` file
located immediately adjacent to itself, saving some path gymnastics.
During our computation to create `runtime-npm-modules.txt` we need to be
careful: pathnames are based on `import.meta.dirname` now and are
therefore always absolute: we need to adjust our logic for finding paths
starting with `node_modules` to consider the relative pathname.
Stop hardcoding 'dist/' all over the place. We already do it once in
the esbuild configuration blob, and that's enough. The other places
(and particularly the plugins) should be reading it from there.
For the qunit plugin, remove a hardcoded instance of 'qunit/'.
The anaconda WebUI branding symlinks point to files from fedora-logos.
Fedora < 46 does not ship those files, so the symlinks are
expected to dangle there.
Remove the anaconda brand color pallete and PatternFly token mapping.
This is now provided by the distribution's logos package via the
imported anaconda-branding.css. [1]
Also remove the .anaconda .logo rule from branding.css. It is now
defined in the imported anaconda-branding.css from fedora-logos.
Add a webui-header-logo.png symlink pointing to the logo provided
by the distribution's logos package at
/usr/share/anaconda/pixmaps/webui-header-logo.png, so cockpit-ws
can serve it.
For fedora branding, create two unconditional symlinks:
anaconda-branding.css pointing to webui.css (new name) and
anaconda-branding-compat.css pointing to fedora-webui.css
(old name). Both are imported in branding.css; the browser
silently ignores the @import that 404s (dangling symlink).
[1] https://forge.fedoraproject.org/design/packages/pulls/2
On Debian testing dropping caches causes ext4 journal writes when
running grep on /usr. This caused CI to flake and made it unable to land
any changes to pkg/metrics.
Switching to dd and reading directly from the block device circumvents
these issues.
On Ubuntu uutils does not properly support iflag=direct, so we keep
using GNU dd:
dd if=/dev/vda of=/dev/null bs=4096 count=1 iflag=direct
dd: IO error: Invalid input
Ability to select individual updates, making updating more flexible.
The selection of individual updates is implemented by using a context
provider and a simple reducer to make UI updates more snappy. A more
naive approach that requires re-rendering the whole state every time
update is (un)selected will freeze up the UI for multiple seconds if
there are hundreds of updates. And for tens of seconds if there are
thousands of updates.
In the mobile layout the "System" label sits 4px lower than the
"Help" and "Session" labels and its box overflows the navbar.
The nav toggle rule also matched `#nav-system-item > .pf-v6-c-button__text`,
so the label span got its own `display: grid`, `grid-template-rows: 28px 1fr`
and `block-size: 100%`. It renders inside a 28px row of its own, which
pushes the text down. The button itself already matches
`button.ct-nav-toggle`, and the nested rules in that block target
menu-toggle/select children that the label span never has.
Dropping the selector puts the label at the same height as the other
navbar labels. Follow-up to #23083.
Signed-off-by: Peter Buchan Jr <pbuchan@redhat.com>
Assisted-by: Claude Opus 5.5
On our new test infrastructure, we have enough CPU/Memory overhead to
spin up without running into issues.
This sleep was very problematic as it made skipping destructive tests
take 15 seconds in total. On an Arch test run 5 skipped tests takes up 1
minute of idle waiting time.
