Use the CockpitRsyncWebpack plugin to optionally rsync build code to a
remote machine, the destination is determined by looking at the
package.json's name field.
The node_modules cache tarball will be published as release artifact, to
make sure that any release can be rebuilt in a reproducible way.
Cockpituous' release-source will call this if available:
https://github.com/cockpit-project/cockpituous/pull/438
Avoid the indirection, and directly call webpack. This avoids adding an
`npm` build dependency if/when the RPM wants to rebuild the webpack
during package build.
This is ugly as it races with other make targets which expect
node_modules/ to exist. It's also unnecessary, we can just tell tar to
ignore node_modules/.
Cockpit 247 changed cockpit-po-plugin.js to always expect a line number
in msgid references [1]. Also sync manifest2po from Cockpit 249 to
generate that reference for manifests, so that they keep getting
included into the translation js.
[1] 0ecc3a705d
731fdf82c0 fixed the
deprecation warning in cockpit-po-plugin:
> node:37175) [DEP_WEBPACK_COMPILATION_ASSETS] DeprecationWarning:
> Compilation.assets will be frozen in future, all modifications are
> deprecated.
> BREAKING CHANGE: No more changes should happen to Compilation.assets
> after sealing the Compilation.
Bring back terser-webpack-plugin from commit c52136c051 and re-enable
it. It builds the autogenerated dist/index.js.LICENSE.txt which is quite
important for shipping distribution packages -- c-{podman,machines} both
do this.
Backport 95021c336e
to make sure that the webpack for the release tarball is *actually*
built in production mode.
Teach `make dist-gzip` to print the tarball name as last line, and use
it as `create-archive` action.
Add a `make print-version` command which packit can use. The builtin
default only works if there is at least one git tag, which is not the
case for starter-kit (which is never released).
Drop the cockpit-po-plugin.js and sassc-loader.js code copies, and check
them out from a stable cockpit tag, similarly to how we already get the
PatternFly CSS.
Convert the `po2json` script into a webpack plugin, and integrate the
(now trivial) po.empty.js template.
This is the last step for building the entire dist/ directory with
`npm run build` (i.e. a tool that web developers are familiar with),
and not having a split webpack+make toolchain any more.
compression-webpack-plugin fixes https://www.npmjs.com/advisories/1548
Adjust to new copy-webpack-plugin API.
Thew new modules now create dist/index.html.gz in `NODE_ENV=production`
mode, so switch `WEBPACK_TEST` to index.css instead (which remains
uncompressed in both modes).
We previously made directories depend on files for the synthetic
serialization of git commands. git does not track directories, and
time stamps across repos (starter-kit vs. bots) work rather poorly --
for example, this broke "bots" being a symlink to a previously existing
checkout.
Use file locking instead, which is a more direct way of ensuring that
there is only one git operation that affects the current checkout. We
don't need to flock bots/, as that's an independent git repository.
Closes#371
This is a relatively recent git feature which is not present in e.g.
Debian 9 yet. Use `git reset` instead, like in the test/common rule.
Fixes#369Closes#370
The `bots`, `test/common`, and `src/lib/patternfly` targets cannot be
run in parallel, as they compete for the git lock.
Serialize them by adding arbitrary dependencies to them.
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.
* 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
