-
Notifications
You must be signed in to change notification settings - Fork 446
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
Update source-build artifacts to be coherent #15372
Conversation
@ViktorHofer - Are you aware of any runtime changes that might be causing the following errors? I am trying to update the SDK to eliminate some prebuilts and the build was working for me on commit 007df054a526ed9e3dc70b43bfa330943bd4816a but started failing after dfe1076090adad6990747e6abed8bf6699371877 flowed in. TIA
|
I can see from a previously successful CI build that it also had these same warnings of LibraryImportGenerator. So that seems unrelated to the cause of this issue. |
This reverts commit 7d4a815.
I kicked off another local build and cannot reproduce this. I am running with |
This sure is strange. I created a codespace from this PR and it doesn't repro there either. 🫤 |
Ah, it repros when using the |
Oh that's a good discovery. Not sure why that is. IIRC clean while building only cleans up artifacts at the end of a repo build. Could this indicate an odd cross repo dependency outside of a nuget package? |
@MichaelSimons I'm currently OOO - sick. Let me cc @jkoritzinsky who might be able to help. |
Could this be related to the fact that Microsoft.Interop.SourceGeneration is building with a prebuilt reference? I just saw the issue related to that on dotnet/runtime and am going to put out a PR to fix it. |
…s/installer into update-sb-artifacts
I've narrowed things down a bit. This behavior does not occur if the arcade and command-line-api repos are not cleaned up after building them. |
One thing I noticed is that if you rebuild after this fails, the build passes. This is an indicator that it isn't clean-while-building related because that only cleans up artifacts after building each repo in the full build context. This could be an indicator of a concurrency issue. |
I am at a loss on this one. I have a working and failing binlog from the same commit. The parameters to the csc command of System.Private.CodeLib.csproj appear to be identical. The question I have is the following warning a red herring? As Matt pointed out earlier, he has found other working builds that pass with this same warnings.
In regards to
I don't think this is related. That PR is in regards to enabling the local prebuilt detection in the runtime repo. |
I also found that if you run build.sh once so that it targets all of runtime's dependencies (and only those dependencies) and then run build.sh again targeting only the runtime repo, the build will succeed. But if you include the runtime repo in that first build, it won't work. |
I've isolated the repro to just the change in the SDK version. The other changes in this PR are not impacting this issue. |
We need to unblock this PR for preview one. I have disabled the clean-while-building functionality and logged a tracking issue to investigate how this is causing the build to fail. |
Co-authored-by: Matt Thalman <[email protected]>
The symptoms of this issue are very similar to dotnet/runtime#85082. Believe it's likely the same underlying problem. |
No description provided.