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.
Follow 1a28b31828 and
move the linters into test/static-code. This also starts to lint files
which are outside of esbuild's realm, such as documentation and
examples.
[1] https://github.com/evanw/esbuild/issues/3542
/usr is package manager territory, and not even writable on OSTree based
systems such as Fedora CoreOS or RHEL Edge. This has been common and
good practice in autotools for decades.
You can still override this with `make install PREFIX=...`. Use that in
the RPM spec file.
Include CSS linting by default for our CSS/SCSS files, originally
introduced in cockpit. The stylelint configuration is copied from
760a4628282e02fbcef3.
This gets rid of our "release" environment with high-profile secrets,
and the cockpituous/release infra.
The upstream release uses our shared
https://github.com/cockpit-project/action-release/ action.
- use https when possible (mostly for cockpit-project.org URLs)
- fix the references to the cockpit and tmt official repositories
- update one packit.dev URL
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.
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).
Travis stopped handing out free credits since their plan changes last
November, so tests have not run since then.
Cirrus CI offers an API similar to Travis, and also explicitly supports
/dev/kvm access.
Eventually we want to use the cockpit/tasks container directly. But we
can't fix the /dev/kvm permissions inside that as `sudo` does not work
in that. Once we fix that, the setup will become much cheaper and
simpler.
Travis now offers /dev/kvm, and its machines are powerful enough to run
our browser integration tests, at least for small projects.
Building an RPM on the Ubuntu host environment is a bit tricky, as there
are no installed RPMs. Thus ignore the BuildRequires, and install
appstream-util explicitly. In the future, the rpm/deb build should
happen inside the VM (like Cockpit does).
Add two scenarios for current Fedora and CentOS 8.
Switch to the "minimal" environment to make the test easier to reproduce
locally and more explicit.
Closes#386
This avoids a lot of moving parts in our infrastructure (webhook,
npm-trigger roundtrip, tasks container), works in exactly the same way
for independent third-party projects, and does not need *any* secret
other than the automatically provided GitHub token.
Let this run early every morning, roughly similar frequency as
cockpituous used to do. Also add a manual trigger, so that we get a
button to run it on demand.
Closes#384
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
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
Rename some files and change some identifiers to be neutral to the
application name. This makes it simpler to change everything to a proper
name when cloning this project.
Document in the README how to find the remaining places to change.
Closes#20
