`job.trace(iterator=True)` is not safe for `.decode()` / per-line processing · python-gitlab/python-gitlab · Discussion #3200 · GitHub
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
-
Heading
-
Bold
-
Italic
-
Quote
-
Code
-
Link
-
Numbered list
-
Unordered list
-
Task list
-
Attach files
-
Mention
-
Reference
👍
1
reacted with thumbs up emoji
👎
1
reacted with thumbs down emoji
😄
1
reacted with laugh emoji
🎉
1
reacted with hooray emoji
😕
1
reacted with confused emoji
❤️
1
reacted with heart emoji
🚀
1
reacted with rocket emoji
👀
1
reacted with eyes emoji
Footer
You can’t perform that action at this time.
Uh oh!
There was an error while loading. Please reload this page.
{{title}}
Uh oh!
There was an error while loading. Please reload this page.
-
According to https://python-gitlab.readthedocs.io/en/stable/gl_objects/pipelines_and_jobs.html#id6, the result of .trace(streamed=False) is/are "entirely stored in memory in this example".
I believe similar behavior can be achieved via iterator=True, though without callbacks.
The function
python-gitlab/gitlab/utils.py
Lines 69 to 89 in 5a4acab
even though it uses response.iter_content, which could support decode_unicode=True (def iter_content(self, chunk_size=1, decode_unicode=False):), but there is currently no way to pass that downward.
The result is a binary stream, which is unworkable as-is for line-based operations - as I "expect"/process the Job Log as a line stream (e.g. match this, ignore that ...). This also mirrors "average Joe's processing" of a job log: Go through it line-by-line, search etc
Not a blocker - just wondering if there is a more elegant, in-library workaround (or solution I have missed).
... or "food for thought" if development is due to happen.
Beta Was this translation helpful? Give feedback.