for each bundle upload both the chunks and the zipped bundle
were kept (even though they are only needed on-upload, i.e.
after extracting we deal with the extracted files exclusively
This is an important step in 'keeping sourcemaps-related data-usage limited'
i.e. see #129
chunk_upload is and has always been working 'for real'. The only sense in
which the comment has been 'vaguely in the direction of truth' was that
with a chunkSize and maxRequestSize of 32MiB in practice sourcemap uploads
will often have been single-chunk in practice.
See #147
i.e. update the comments to reflect what I just learned doing some actual
experiments.
See #147
b.t.w. the now-removed comment was somewhat misleading: "single-chunk"
was (and is) being forced as in "single chunk per request" but not as
in "single chunk per file", and it was only forced by chunksPerRequest=1,
not by concurrency=1.
As per the comment.
Since we haven't actually gone multi-chunk, this is just preparation
The now-removed comment should be read as 'it could be assumed that
unzipping introduces a factor 5 increase between chunk size and file
size' but that's a whole bunch of assumptions that I'd rather get
rid of (mental overhead, with little gain).
See #147
Triggered in particular by the 'You may need to add %r to ALLOWED_HOSTS'
wording in the previous version, which sends you in the wrong direction
when the cause is a proxy-misconfiguration.
See #148
* The "collapse" etc. buttons get shown below the search box and < << >> > from
a certain width downwards.
* similar stacking for the date/type/value and the buttons at an even smaller width.
See #120
Health checks are often done directly against an IP address rather than using a
full hostname. This is annoying to set up if the IP address can be one from a
large range.
The things that ALLOWED_HOSTS defend against don't really apply for health
endpoints, so better not have the check.
Fix#140
* in 1abc30a760 the hardcoding of ="dark" (during development)
was accidentally checked in; it never should have been.
* in e14b3eaaa6 I mixed up the bare*base templates. It's actually
bare_base.html that's for 404/500 etc; barest_base is more bare
visually (it's the box-based layout for login etc), but it doesn't
need to be so careful not to use variables.
See #40
In the light of the discussion on #134, this implements the "clean up later"
solution: a vacuum task that deletes IssueTags no longer referenced by any
EventTag on the same Issue.
In the same sweep TagValues are pruned.
Performance-wise, this is a relatively safe path forward; it can run off-hours
or not at all, depending on preferences.
Semantically it's the least clear: whether an Issue appears to be tagged may
now depend on whether vacuum has run, and `IssueTag.count` (representing total
observed) is left in a "weird place" in the sense that it may disappear from
the total more or less at random (i.e. depending on calling a command, and
depending on the current state of not-yet-evicted Events).
In the light of the discussion on #134, this implements the "clean up later"
solution: a vacuum task that deletes IssueTags no longer referenced by any
EventTag on the same Issue.
This doesn't prevent stale IssueTags from being created but ensures they are
eventually removed, enabling follow-up cleanup (e.g. of TagValues).
Performance-wise, this is a relatively safe path forward; it can run off-hours
or not at all, depending on preferences. Semantically it's the least clear:
whether an Issue appears to be tagged may now depend on whether vacuum has run.
No tests yet; no immediate TagValue cleanup.
My thinking:
* Avoid Dependabot spam for harmless version bumps. (sentry-SDK
has the most upgrades by an order of magnitude)
* In princple, there should be no breakage, b/c they do semver and
"minor version when you add functionality in a backward compatible manner"
* This is dev tooling; it shouldn’t be a source of friction.
* As it stands: I'm not thoroughly reviewing these anyway (b/c of the spammyness)
The alternative would have been to "just freeze" it; if we ever run into
problems because of the unpinning I certainly will.
my chatbot tells me it felt ugly because
> bg-yellow-900 [..] is a very saturated, reddish mustard — almost
> brown-orange. That’s why it feels so jarring in dark mode: it's too warm,
> too saturated, and clashes with a cool-dark UI. [..] Try bg-amber-800
> instead. Tailwind's amber palette is warmer and more muted than yellow,
> designed to fit better in dark UIs.
No idea if the reasoning is sound, but it "looks good" so I'm pushing ahead.
