Restore task element name / element name distinction in UI #1428
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 6 commits
October 1, 2020 17:01
Instead of passing around untyped tuples for cache keys, lets have a clearly typed object for this. This makes for more readable code, and additionally corrects the data model statement of intent that some cache keys should be displayed as "dim", instead informing the frontend about whether the cache key is "strict" or not, allowing the frontend to decide how to display a strict or non-strict key. This patch does the following: * types.py: Add _DisplayKey * element.py: Return a _DisplayKey from Element._get_display_key() * Other sources: Updated to use the display key object
Instead of using Element._get_brief_display_key(), no need for that second accessor.
Now that we have _DisplayKey(), no need for this extra accessor, it's not helping anything to have it anymore.
This allows more flexible usage of the APIs, to allow passing all of the Message() constructor arguments through kwargs.
This behavior has regressed a while back when introducing the messenger object in 0026e37 from merge request !1500. Main behavior change: - Messages in the master log always appear with the task element's element name and cache key, even if the element or plugin issuing the log line is not the primary task element. - Messages logged in the task specific log, retain the context of the element names and cache keys which are issuing the log lines. Changes include: * _message.py: Added the task element name & key members * _messenger.py: Log the element key as well if it is provided * _widget.py: Prefer the task name & key when logging, we fallback to the element name & key in case messages are being logged outside of any ongoing task (main process/context) * job.py: Unconditionally stamp messages with the task name & key Also removed some unused parameters here, clearing up an XXX comment * plugin.py: Add new _get_message_kwargs() method to collect the kwargs appropriate to construct Messages() issued by the plugin. Use this method to construct messages in Plugin.__message() and to pass kwargs along to Messenger.timed_activity(). * element.py: Override _get_message_kwargs() so as to provide the cache key in messages issued by this element. * tests/frontend/logging.py: Fix test to expect the cache key in the logline * tests/frontend/artifact_log.py: Fix test to expect the cache key in the logline Fixes #1393
|
In GitLab by [Gitlab user @tristanvb] on Sep 23, 2020, 07:43 added 13 commits
|
|
In GitLab by [Gitlab user @tristanvb] on Sep 23, 2020, 11:39 added 8 commits
|
|
In GitLab by [Gitlab user @tristanvb] on Sep 24, 2020, 12:13 added 11 commits
|
|
In GitLab by [Gitlab user @tristanvb] on Sep 25, 2020, 08:02 added 9 commits
|
|
In GitLab by [Gitlab user @tristanvb] on Oct 1, 2020, 09:02 added 26 commits
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See original merge request on GitLab
In GitLab by [Gitlab user @tristanvb] on Sep 21, 2020, 10:05