Skip alert for RelVals with deletable pileup #11283
Conversation
|
Jenkins results:
|
|
Jenkins results:
|
|
Jenkins results:
|
|
test this please |
|
Jenkins results:
|
Fix Workflow data structure to use isRelVal function update MSOutputTemplate to use the common function fix docstring
fix more unit tests
|
Jenkins results:
|
| @@ -200,6 +201,7 @@ def docSchema(self): | |||
| docTemplate = [ | |||
| ('RequestName', None, (bytes, str)), | |||
| ('RequestType', None, (bytes, str)), | |||
| ('SubRequestType', None, (bytes, str)), | |||
There was a problem hiding this comment.
Due to this change I want to raise your awareness of consequences of having multiple data-type assignments to a single variable. Why do you do that? Such assignment only creates other problems down in the road making checks, and code to do extra work and hide issue with data-types. All conversions should be done in place and attributes in a document should have single data type. But it is my view and I doubt you'll make the changes. But as reviewer I want to want you about it.
For instance, if this code produce data with different data-type (in a list one document will have bytes data-type in another document it will be a string), the issue will raise in a client code which can't process the data using a parser which relies on specific data-type. Especially if such code is statically typed language (C/C++, Go, etc.) In such languages parser can't assign different data type to a variable with certain data-type. As such such data will fail to parse in such languages.
There was a problem hiding this comment.
Byte and unicode strings was very hard to deal while making WMCore compatible with py2 and py3. As we start removing python2 code and making WMCore python3-only, we should definitely revisit strings and try to converge to a single type as much as we can in the project. Good point!
For now, I am just following the stream here.
Fixes #11279
Status
not-tested
Description
Change was supposed to be very basic as of not creating alert notifications for Release Validation workflows. However, we cannot distinguish RelVals from non-RelVals in MSRuleCleaner, hence the code refactoring avoiding to duplicate code.
Note that this PR adds a new
SubRequestTypekey/value to the MSRuleCleanerWflow data structure.Is it backward compatible (if not, which system it affects?)
YES
Related PRs
None
External dependencies / deployment changes
None