- 
                Notifications
    
You must be signed in to change notification settings  - Fork 4.3k
 
Remove test wall time from xml_test_generator usage #27382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
          
     Open
      
      
            werkt
  wants to merge
  1
  commit into
  bazelbuild:master
  
    
      
        
          
  
    
      Choose a base branch
      
     
    
      
        
      
      
        
          
          
        
        
          
            
              
              
              
  
           
        
        
          
            
              
              
           
        
       
     
  
        
          
            
          
            
          
        
       
    
      
from
werkt:test-xml-discard-duration
  
      
      
   
  
    
  
  
  
 
  
      
    base: master
Could not load branches
            
              
  
    Branch not found: {{ refName }}
  
            
                
      Loading
              
            Could not load tags
            
            
              Nothing to show
            
              
  
            
                
      Loading
              
            Are you sure you want to change the base?
            Some commits from the old base branch may be removed from the timeline,
            and old review comments may become outdated.
          
          
  
     Open
                    Changes from all commits
      Commits
    
    
  File filter
Filter by extension
Conversations
          Failed to load comments.   
        
        
          
      Loading
        
  Jump to
        
          Jump to file
        
      
      
          Failed to load files.   
        
        
          
      Loading
        
  Diff view
Diff view
There are no files selected for viewing
  
    
      This file contains hidden or 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
    
  
  
    
              
  
    
      This file contains hidden or 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
    
  
  
    
              
  
    
      This file contains hidden or 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
    
  
  
    
              
  
    
      This file contains hidden or 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
    
  
  
    
              
  
    
      This file contains hidden or 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
    
  
  
    
              
  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.
  
    
  
    
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very useful for interop with test infrastructure that isn't Bazel-aware. JUnit XML is pretty much universally supported, other means for getting this information would need an adapter.
Generally speaking, wouldn't the test logs, which are also inputs to this action, usually be non-deterministic as well? In that case the XML generation spawn would differ anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test outputs can be deterministic, or not. The problem here is that regardless of whether they are, if the wall time for the test crosses a second threshold, it automatically changes the command definition from one value to the next, and prevents even deterministically outputting tests from avoiding differences between no-change builds being run to locate determinism issues elsewhere. Objectively, the test isn't in control of whether it gets scheduled enough to avoid modifying its own wall time, no matter how much an author seeks deterministic, reproducible output.
I'm game for marking this up as a test-command option, but figured it may be more useful to avoid this very subjective data altogether than try to cobble conditional xml output.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I see how it can be annoying that this introduces non-determinism into an otherwise deterministic test, I've honestly never seen a non-trivial project in which every test emits a deterministic log. In the context of detecting non-determinism, getting rid of the runtime argument would only really make a qualitative difference if that was the case though.
bb explainhas special handling for this particular spawn, which is recognized by itsTestRunnermnemonic and the basename of the output. What do you think of introducing a distinctive mnemonic (sayTestXmlGeneration)? That would make it very easy to filter this out without taking away value from non-Bazel-aware test integrations.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The mnemonic should be switched regardless of the outcome here. Qualifying this activity with the TestRunner is ambiguous and something I've wanted changed for a while, I will submit a separate change.
It's not satisfactory though to say that unlikeliness of universal determinism is a reason to permit this behavior to introduce arbitrary nondeterminism. Cases where overt remote cache misses occur here solely because of this change is the domain of this improvement. Less convincing still is the interest to maintain external tooling. I don't have the option to disable this step of output entirely from bazel's execution, and I don't necessarily know that removing this timing will break any particular downstream parser to ignore the missing content (and its obvious duplication for the use in two fields).
Real timing information is clearly available in bazel-specific contexts, because it exists at higher precision than 1s.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @meisterT @tjgq
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One better than this with further thought. This is a mechanism that, outside of java, no other user of bazel can perform (starlark for instance): modifying the composite state of an action in its command args such that they are only effective and known during the execution phase. I don't care about the presence in the xml, it can be zero for all that matters here, but the unpredictable nature of the action makes the graph mutable, something against the stated intention of bazel. This represents bazel mutating its own "immutable build graph".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a breaking change to multiple repos I'm aware of. Can we at least put it behind an incompatible flag?
(+1 that in my experience most tests do not have deterministic logging, it's common for logs to contain randomly-generated IDs, timestamps, etc.)
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which situation are you referring to here? If the test execution itself is a cache hit, the subsequent XML generation should be as well since the test runtime is obtained from the cached action result. If a test is forced to rerun somehow then this action could potentially be a cache hit if it didn't contain the time, but that seems to be a pretty rare case.
Note that rules can always avoid running this spawn by generating the XML directly as part of the test action. But that's of course not something users can add without patching or forking rules they don't own.
Starlark can't access action timing data, but aren't tree artifacts and the newly exposed action templates examples of this?