Enter the new world of GitHub actions [1]/GitLab pipelines [2]. This
simplifies our end of the infrastructure considerably:
* No need any more to set up webhooks, all the relevant configuration
is right in the workflow file.
* Does not need any infrastructure on our side any more, and thus works
for third-party projects. They just need to set up their own secrets.
* GitHub automatically provides a temporary `GITHUB_TOKEN` with
sufficient write access to the project to publish a release, so we
don't need to carry around that secret. Thus if your project only
releases to GitHub, there is zero secrets management.
Also adjust cockpituous-release a bit (update Fedora version, fix
project name copy-pasta), point to the action workflow and necessary
secrets.
Closes#380
The current version failed with
Option "--directory" requires 1 arguments, but 0 were provided
In the current stdio npm module version, getopt() now requires a
`default:` attribute, otherwise it considers the options as required.
Also sync PO helpers with current cockpit.
Add PO template build to travis check, to make sure that it keeps
working.
Closes#375
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
Import our application CSS as the very last thing, so that it can
properly override PatternFly variables. Before, our application CSS
could land in the first third of dist/index.css *before* PatternFly's
definitions, so that the latter overrode the former [1].
This is a long-standing bug in mini-css-extract-plugin ([2] and
countless things that point to it) with `NODE_ENV=production` builds.
As a workaround, make sure that app.scss is the absolutely last imported
CSS, instead of "almost last". It is still conceptually correct for the
application CSS to be able to override patternfly-4-overrides.scss.
Closes#362
[1] https://github.com/martinpitt/performance-graphs/issues/10
[2] https://github.com/webpack-contrib/mini-css-extract-plugin/issues/188
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.
This recently started to overflow inotify, and we don't need that --
it's fine to restart webpack when changing package.json, and it happens
rarely enough.
Closes#345
Nobody in the development team has ever really used that, it needs a ton
of dependencies, and doesn't work in toolbox/Silverblue. Our own
vm-run/image-customize etc. machinery is efficient enough, and proven to
work.
Closes#321
* Stop importing cockpit's base1/patternfly.css
This is deprecated API and will be dropped at some point, in favor
of projects shipping their own CSS.
Install and import the styles from PF4 now.
* Use webpack based string replacement for removing the font-face rules from PF4
Doing the seddery in Makefile breaks `npm run build`, webpack watching,
and is generally brittle.
Do the font replacement hacking with `string-replace-loader`, which fits into webpack much more nicely.
There is still some potential simplification by not duplicating the
entire scss loader chain.
Co-authored-by: Martin Pitt <martin@piware.de>
Closes#315
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.
