Similar to what cockpit-composer does. This is rather simplistic, but
does fine until we need more complex scenarios.
Also use plain shell in test/run, there are no bashisms.
Closes#291
Avoid phony dependencies, as they break timestamp comparison and thus
always cause rebuilding of the tarball, rpm, and (the very expensive) VM
for each `make check`, even if only the tests (or nothing at all)
changed.
Use `rpmspec` to predict the name of the built rpm. Use the .spec.in
file directly, as we can't depend on the generated .spec file in the
variable definition.
Closes#290
Use `%{VERSION}` as version macro instead of `@VERSION@`, so that the
.spec.in file is syntactically a correct spec file that can be parsed
with `rpmspec`.
We don't need the full cockpit metapackage with cockpit-docker, etc.
The starter-kit RPM will already pull in cockpit-system, so we just need
cockpit-ws.
It looks like Webpack is deprecating extract-text-webpack-plugin in favor of
mini-css-extract-plugin.
Discussion can be found here: webpack-contrib/extract-text-webpack-plugin#731
Closes#271
These make components with simple state (only a few variables) easier to
read and maintain. See https://reactjs.org/docs/hooks-intro.html for
details. Hook are available since React 16.8, and we already depend on 16.10.
We can't use hooks in our actual code, as our only `Application`
component needs a constructor. But this enables the ESLint plugin to
guide developers to the right path if they use hooks.
Closes#239
* If `$COCKPIT_BOTS_REF` is set, check out that bots version instead of
master.
* Use git cache in $XDG_CACHE_HOME if available. Our CI uses that to
save downloads, and it does not get in the way for local developers.
* Stop making "bots" a phony target, and drop the now unnecessary
`[ -d bots ]` check.
Closes#233
Commit 95b2aff0 was a thinko -- for our CI we *don't* want our test to
clobber a pre-existing bots/ checkout, as we often use this to run tests
against an updated image or to validate a changes to the bots project.
On developer machines, bots may also be a symlink to an actual bots
directory in development, so don't clobber that.
Closes#232
This is meant to only control webpack. But `npm install` skips
installing `devDependencies` under `NODE_ENV=production`, which breaks
the package build. So always unset it for npm.
This fixes `NODE_ENV=production make` in a clean tree.
`npm install` does not update/touch an already existing
package-lock.json. Thus after
make
touch package.json
make
a subsequent `make` would still run `npm install`. To fix this, remove
package-lock.json before `npm install`, so that (1) package-lock.json
always gets touched and thus the make rule actually works, and (2)
during development we always get up to date packages (we only really
want the "locking" behaviour for building from release tarballs).
Also run `npm prune` so that switching between git trees with
added/removed modules works correctly.
Closes#223
npm install has been generating package-lock.json [1] for long enough
for us to start relying on it.
Replace the unreliable and hacky `$NODE_MODULES_TEST` file with just
comparing package.json against package-lock.json to decide when to run
npm install. This will finally avoid unnecessary `npm install` runs, but
start to run these when git switching branches that have a different
package.json.
Ship package-lock.json in release tarballs, so that node_modules/ can be
reconstructed exactly as it was when making the release.
[1] https://docs.npmjs.com/files/package-lock.jsonCloses#222
This gets rid of a deprecated transitive dependency:
deprecated nomnom@1.8.1: Package no longer supported. Contact support@npmjs.com for more info.
Closes#221
