Add docker logs plugin

[JSCU-CNI]

As discussed in #441.

[JSCU-CNI]

Thanks for the thorough review @Schamper and @Horofic. I've implemented all feedback where applicable and replied to all comments where things are still unclear.

[codecov]

Codecov Report

Attention: 14 lines in your changes are missing coverage. Please review.

Comparison is base (6a42513) 73.69% compared to head (fd6b1be) 73.79%.

Files	Patch %	Lines
dissect/target/plugins/apps/container/docker.py	89.74%	12 Missing ⚠️
dissect/target/target.py	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #507      +/-   ##
==========================================
+ Coverage   73.69%   73.79%   +0.10%     
==========================================
  Files         278      279       +1     
  Lines       23153    23272     +119     
==========================================
+ Hits        17063    17174     +111     
- Misses       6090     6098       +8     

Flag	Coverage Δ
unittests	73.79% <90.66%> (+0.10%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JSCU-CNI]

Thanks @Horofic. There seems to be a race condition in the order in which records are returned. I am unable to reproduce the failing tests locally. Unfortunately sorting on records is not possible, what do you recommend as a fix?

[Schamper]

Thanks @Horofic. There seems to be a race condition in the order in which records are returned. I am unable to reproduce the failing tests locally. Unfortunately sorting on records is not possible, what do you recommend as a fix?

Maybe the test log files are iterated/loaded in a different order (based on some filesystem/Python listdir quirk).

[Horofic]

Thanks @Horofic. There seems to be a race condition in the order in which records are returned. I am unable to reproduce the failing tests locally. Unfortunately sorting on records is not possible, what do you recommend as a fix?

Maybe the test log files are iterated/loaded in a different order (based on some filesystem/Python listdir quirk).

Check. In that case, incorporating the last remarks from @Schamper should do it.

[Schamper]

Thanks @Horofic. There seems to be a race condition in the order in which records are returned. I am unable to reproduce the failing tests locally. Unfortunately sorting on records is not possible, what do you recommend as a fix?

Maybe the test log files are iterated/loaded in a different order (based on some filesystem/Python listdir quirk).

Check. In that case, incorporating the last remarks from @Schamper should do it.

It was a remark at a possible cause, the suggestion wasn't to fix that 😄

[JSCU-CNI]

Perhaps fox-it/flow.record#108 fixes this when adding results.sort() in the tests or the following for the meantime:

import operator
results.sort(key=operator.attrgetter('_generated'))

Interesting to see the 3.12 CI environment does not seem to be impacted by this.

[Schamper]

Perhaps fox-it/flow.record#108 fixes this when adding results.sort() in the tests or the following for the meantime:

import operator
results.sort(key=operator.attrgetter('_generated'))

Interesting to see the 3.12 CI environment does not seem to be impacted by this.

I don't think this will fix the problem, as I think the problem lies in the order at which the log files are mapped into the virtual filesystem. At least on my local system, it gets mapped correctly, but for some reason in the CI it gets mapped the other way around (probably something to do with timestamps).

Sorting on the record content (e.g. ts, message) should result in a consistent test output.

[JSCU-CNI]

Seems like the pypy39 pipeline is having a rough Friday :(

Fatal Python error: Segmentation fault

[Schamper]

Seems like the pypy39 pipeline is having a rough Friday :(

Fatal Python error: Segmentation fault

Yeah unfortunately the PyPy 3.9 CI does that. We have to keep re-running it until it doesn't segfault 😄