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.
we now have handling for them, no need to keep seeing them as stacktraces.
also: in the EAGER setup, raising means the transaciton is rolled back,
and nothing is stored in the DB at all.
if we ever want to 'get more info' something like capture_or_log_exception
would be more apt
As per the parent commit: the "small check" is not bullet-proof (as per #99)
and in Docker/systemd environments it's better to leave the thing that's
actually in charge of lifecycles in charge rather than reproduce that behavior.
You can’t fail the check if you deliberately skipped it.
Fix#99
As implied by this comment:
> this implementation is not supposed to be bullet-proof for race conditions (nor is it cross-platform)... it's
> just a small check to prevent the regularly occurring cases:
> * starting a second runsnappea in development
> * running 2 separate instances of bugsink on a single machine without properly distinguishing them
but this "small check" gets in the way sometimes, so it's better to be able to turn it off.
See #99
on the subject of this being the 3rd time (or more) that I'm fixing this:
> even a donkey typically doesn't bump into the same stone twice (Dutch proverb)
Q: but what animal put the stone there in the first place?
A: Python's lanuage "designers"
in the correct timezone, with smaller milis
According to the spec, this should work because:
> The timestamp of the breadcrumb. Recommended. A timestamp representing when
> the breadcrumb occurred. The format is either a string as defined in [RFC
> 3339](https://tools.ietf.org/html/rfc3339) or a numeric (integer or float)
> value representing the number of seconds that have elapsed since the [Unix
> epoch](https://en.wikipedia.org/wiki/Unix_time). Breadcrumbs are most useful
> when they include a timestamp, as it creates a timeline leading up to an
> event.
the store API is deprecated and b/c it doesn't support the ingest/digest
split can be quite confusing.
this is similar to 2b8efc9452 (for the stress_test command the 'store'
API option was removed entirely)
Klaas van Schelven