-
Notifications
You must be signed in to change notification settings - Fork 231
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
Fix S2342 FP: Flaky reports #9683
Comments
Hey there, Can you clarify what you mean by this?
|
Yeah, these things are usually hard to diagnose. I was just guessing, without looking at the source code. It may as well be a race condition somewhere in Sonar code or the underlying compiler. The project where this happens is open-source under the .NET Foundation. Sources are at https://github.com/SteeltoeOSS/Steeltoe. I've tried to dig up a build log, but couldn't find it back in the large amount of builds. I'll post it here when it happens again. |
This issue popped up again on Friday during this run on a Microsoft-hosted MacOS pipeline, here is the output from the failed step:
|
Hello, I looked into your project and it seems, that the error is raised when the ConfigurationSchemaGenerator.csproj project is build and/or run. That project does it's own Roslyn based compilation here and raises its own issues, like here. My suspicion is that during the compilation that takes place when I would recommend to run Note: I haven't studied what |
Hi @martin-strecker-sonarsource, thanks for looking into this. We maintain a copy of Aspire's generator because there's no NuGet package for it. It executes during build, producing a JSON schema file (that gets embedded in our output NuGet package) to enable IntelliSense in Visual Studio for I don't think Sonar analyzers run during build of the tool, because it has no references to Sonar: I also don't think Sonar analyzers run when the tool executes (which is when other projects are built). You can verify by uncommenting the ConfigSchemaGenerator.GenerateSchema(inputAssembly, references, outputFile); Once the breakpoint is hit, the list of references does not include any Sonar assemblies. Disassembly of |
Thank you for the clarifications. I looked into the other successful runs and it seems indeed unrelated to I haven't found another failing build step here and I was wondering if the failure is specific to MacOS (you mentioned Ubuntu in the issue description but I haven't found a failing build there). Have you seen the same error in other builds on other platforms? The background is that I have a hard time to understand what can possibly be flaky here. The RegEx looks as expected and the position in code found is correct. Can you please also link to the pipeline yaml definition for these builds. It would also help if you could turn verbose mode on and send us the logs for a failed run: - task: SonarCloudPrepare@3
inputs:
SonarCloud: 'sonarcloud'
organization: 'foo'
scannerMode: 'dotnet'
projectKey: 'foo_sonar-scanning-someconsoleapp'
projectName: 'sonar-scanning-someconsoleapp'
extraProperties: |
sonar.verbose=true The important logs are in the END step (i.e. SonarCloudAnalyze / “Run Code Analysis”) The build should also be executed with verbose logs:
Thank you. |
The failure on Ubuntu was months ago, those logs have been cleaned up by now. Pipeline yaml files are at https://github.com/SteeltoeOSS/Steeltoe/tree/main/build and https://github.com/SteeltoeOSS/Steeltoe/blob/main/azure-pipelines.yml. What's the performance impact on activating verbose logging? Given the failure occurs only once every few months. |
Also, note the failures haven't occurred in the Sonar build pipeline so far, so we'd need verbose logging in all pipelines. |
Description
During ci-build, we randomly get build errors such as the following:
The affected
[Flags]
enum is namedFastTestConfigurations
, which complies with the rule. Because we sometimes get this error, but not always, I suspect a static regex is being used that isn't thread-safe.Repro steps
Not available, it happens randomly, but not always. I've seen this multiple times in Azure DevOps, running on Ubuntu against .NET 8. I haven't experienced it locally on Windows 11.
Known workarounds
Restart the cibuild, which usually makes the error go away.
Related information
The text was updated successfully, but these errors were encountered: