The release workflow wants to use --provenance but the update fails:
Run npm install -g npm
npm ERR! code EACCES
npm ERR! syscall mkdir
npm ERR! path /usr/local/share/man/man7
npm ERR! errno -13
npm ERR! Error: EACCES: permission denied, mkdir '/usr/local/share/man/man7'
npm ERR! [Error: EACCES: permission denied, mkdir '/usr/local/share/man/man7'] {
npm ERR! errno: -13,
npm ERR! code: 'EACCES',
npm ERR! syscall: 'mkdir',
npm ERR! path: '/usr/local/share/man/man7'
npm ERR! }
npm ERR!
npm ERR! The operation was rejected by your operating system.
npm ERR! It is likely you do not have the permissions to access this file as the current user
npm ERR!
npm ERR! If you believe this might be a permissions issue, please double-check the
npm ERR! permissions of the file and its containing directories, or try running
npm ERR! the command again as root/Administrator.
So we fix it by just telling the action what we want rather than monkey patching it.
Link: https://github.com/thelounge/thelounge/actions/runs/8580746748/job/23517165611
If we specify the spec in the config file, we can't manually
specify a specific test file from the cli.
This is annoying, as the alternative is copying out the full
package.json blurb into the shell.
Rather, give the spec in the invocation and add a helper
that makes testing a specific file simple.
With this `yarn test:nospec test/plugins/link.ts` will only run
tests within that file
Tests should run the tests, not the coverage.
Frequently one is debugging a test, the coverage won't change
between runs but it delays the cycle considerably.
Rather, if one wants to look at the coverage, one should use
the "coverage" command
Overriding the built in is poor form, as this prevents adding
a new type handler with its own normalize handler.
We only ever want to override protocol-less URLs to http, so
we just do so explicitly in the "//" schema normalizer.
This also means that we don't need all that type conversion dance,
we simply set the schema to null when we patch it and filter on the
schema directly
Introduce the ability to clean up old messages from the sqlite db.
The StoragePolicy can be chosen by the user. Currently there's
two versions, delete everything based on age is the obvious.
The other is for the data hoarders among us. It'll only delete
message types which can be considered low value... Types with
a time aspect like away / back... joins / parts etc.
It tries to do that in a sensible way, so that we don't block
all other db writers that are ongoing.
The "periodically" interval is by design not exposed to the user.
Make the cleaner available to users by exposing it as a subcommand
to thelounge storage.
This is recommended to be run whenever the storage policy significantly
changes in a way that makes many messages eligible for deletion.
The cleaner would cope, but it'll be inefficient and can take many hours.
Due to how storage works in sqlite, the space would not actually be
given back to the OS, just marked for future writes.
Hence this also runs a vacuum to compact the DB as much as it can.
Once this is getting hooked up, it'll periodically delete old
messages.
The StoragePolicy can be chosen by the user, currently there's
two versions, delete everything based on age is the obvious.
The other is for the data hoarders among us. It'll only delete
message types which can be considered low value... Types with
a time aspect like away / back... joins / parts etc.
It tries to do that in a sensible way, so that we don't block
all other db writers that are ongoing.
The "periodically" interval is by design not exposed to the user.
This is laying the foundation to build a cleaning task that's
sort of database agnostic.
All calls are done by acting on a "DeletionRequest" so interpretation
of the config will go through a single point
