Notification for subscribed users from https://github.com/dotnet/roslyn:

@dotnet/roslyn-infrastructure

Action requested: Please take a look at this failing automated dependency-flow pull request's checks; failures may be related to changes which originated in your repo.

• This pull request contains changes from your source repo (https://github.com/dotnet/roslyn) and seems to have failed checks in this PR. Please take a peek at the failures and comment if they seem relevant to your changes.
• If you're being tagged in this comment it is due to an entry in the related Maestro Subscription of the Build Asset Registry. If you feel this entry has added your GitHub login or your GitHub team in error, please update the subscription to reflect this.
• For more details, please read the Arcade Darc documentation

@dotnet/source-build MSBuildLocator got bumped in dotnet/roslyn@9c6403e, do we just bump the submodule in SBRP or is there more?

MSBuildLocator got bumped in dotnet/roslyn@9c6403e, do we just bump the submodule in SBRP or is there more?

ping @dotnet/source-build on the above. dotnet/runtime is pending some metadata changes around the extension members feature and it would be nice to ensure flow isn't blocked.

I think that is correct. @ellahathaway or @mthalman to confirm.

I think that is correct. @ellahathaway or @mthalman to confirm.

Yes, you'll have to update the submodule. The full set of instructions can be found here.

Thanks! That was just completed in dotnet/source-build-reference-packages#1340

I'm going to try and push things through, but this should all flow automatically by tomorrow.

I merged in the latest SBRP flow which contains the MSBuildLocator update

Thanks @ellahathaway!

Looks like there's a complaint about the SHA and BAR ID not being correct in the source-manifest.json. Is there an easy way to resolve that?

@dotnet/product-construction on the code flow error. Is there an easy way to help ensure the source-manifest is correct for cases like this or is it manual?

The changes "look" simple, but want to ensure it's being handled correctly here.

@dkurepa @premun I think the Code flow verification failure is incorrect here. Based on the PR source, the last flow applied was 9c6403e, which the source manifest reflects. However, the PR tracking info seems to think build 28606 was applied on top of that,...and it doesn't appear to be the case. The code flow verification started failing earlier when new changes from main were merged in.

Attempting to manual forward flow the newer roslyn into the VMR shows the following error...so no idea how to get this into the right state.

info: Flowing roslyn's commit 7ead97f to VMR at C:\d\...
info: Last flow was back flow: b7ad826c308d3b0376ed21450271439a97f77f02 -> 73ea6887cb8abecabf3dcd3b8109d4336690afe9
info: Current flow is in the opposite direction
info: Synchronizing roslyn from 4b825dc642cb6eb9a060e54bf8d69288fbee4904 to C:\r\roslyn / 7ead97fc404947f81a4ee3c6543212d60fddfd03
info: Updating VMR roslyn from 9c6403e to 7ead97f..
info: Creating patches for roslyn in C:\Users\mmitche\AppData\Local\Temp\..
info: 1 patch created
info: Applying patch C:\Users\mmitche\AppData\Local\Temp\roslyn-4b825dc-7ead97f.patch to src/roslyn...
info: Cleaning the working tree directory C:\d\src\roslyn...
info: Updating .config/CredScanSuppressions.json...
info: .config/CredScanSuppressions.json updated
info: Committing..
info: Committed in 2 seconds
info: Cleaning the working tree directory C:\d\....
info: Cleaning up...
fail: Failed to synchronize repo to VMR
      Failed to create a patch C:\Users\mmitche\AppData\Local\Temp\78a4010c-3a8d-4f0c-ba46-1be6d4161d1a.patch
      Exit code: 128
      Std err:
      E: unsupported filetype C:\Users\mmitche\AppData\Local\Temp/git-blob-a21976/csharp-diag.docx
      fatal: unable to read files to diff

@mmitche can we trigger a net new pr and cherry-pick everything but the source-manifest changes from dotnet/sbpr?

-- That's essentially what I ended up doing. Closed this one, ran the darc command to trigger a new update, and then cherry-pick the commiit into #1837

The following files had trivial conflicts which needed resolution, just ensuring 10.0.0-beta.25409.103 was picked instead of 10.0.0-beta.25407.105:

src/source-build-reference-packages/eng/Version.Details.props
src/source-build-reference-packages/eng/Version.Details.xml
src/source-build-reference-packages/global.json

And then source.manifest.json which only needed the dotnet/source-build-reference-packages entry fixed to match what was done by darc in that PR

The CI is no longer instantly failing and things are looking better