Having this as a model field is "annoying" because each added language
will trigger a (potentially costly) migration even though no real database
work is actually done for it.
Also implements a selector that shows languages in both their own language
and the currently activated language.
Correct spelling to "zh-hans" (lowercase); see https://stackoverflow.com/a/7729311
See #161
we only support one kind: files.
(in the past it was useful to send-to-self already uploaded items,
but this idea is never used in practice, and the whole idea of having to supply a
'kind' on the cmdline is confusing)
Using patterns here to play well with our excellent dogfood error
tracker:
When the non-validating value is displayed in the exception value, this makes
grouping not work (every event is its own issue); the approach has no upside,
because in a dogfooded setup the local vars are known anyway.
Before this commit, the COPY command was still used to copy-over 2 files from
the working dir. Alhtough this was probably fine in practice (docker build
typically happens from a checked out state that matches the wheel you're
docker-building) it's not what's on the tin ("from wheel") and it opens up
the possiblity of subtle bugs (file mismatches when building from a different
state). Better prevent those.
rather than think-carefully-and-explain-with-nosec, just switch to
safe_join: this saves future readers the pain of validating whether
all assumptions are (still) correct at a (small) performance cost.
See #175
i.e. B380: No os.path.join misuse.
See https://github.com/bugsink/spoils
rather than think-carefully-and-explain-with-nosec, just switch to
safe_join: this saves future readers the pain of validating whether
all assumptions are (still) correct at a (small) performance cost.
See #175
headers means: envelope headers and item headers.
Provides more robustness and a layer of defense-in-depth
Only those headers that we might rely on in a near future (event-based)
are included.
See #173
Even though '_os' suggests a private interface, this is likely to be stable
(for our purposes, i.e. may get more secure); if it ever isn't our tests
will expose it.
See #173
working in the assumptions that:
* 1.*.x is not valid, explicitly listing is needed
* In GitHub Actions, workflow evaluation happens from the main (or default) branch of the repo, not from the branch being pushed to or pulled from.
For some reason the env-vars were missed; pulling them closer hopefully fixes
this (and makes more sense generally)
the `|| true` pattern was removed: it just hides problems.
also: different username (email) to stick closer to what we do elsewhere.
