[automated] Merge branch 'release/2.1' => 'release/2.2'#31131
Conversation
For any packages that we doin't want to ship and marked as BlockStable we should always force include the label and build number in the package name.
) (dotnet#30744) * Fix compilation for deprecated API on macOS Mojave preview Fixes: #30599
Allows include build number for packages blocked from going stable
…708-02, servicing-26708-02, respectively
…pdateDependencies Update CoreClr, CoreFx, CoreSetup to servicing-26708-02, servicing-26708-02, servicing-26708-02, respectively (release/2.1)
…otnet#30954) This change adds support for 308 redirects to SocketsHttpHandler, and enables 308 redirects in our tests. Fixes: #30389
* Tests for #30263 fix Goes with dotnet/coreclr#18460 * Add case for `C:\` to `D:\`
Merge changes into release/2.1
Always run end.ps1/sh
We need to generate the buildversion props file before we start a parallel build otherwise we race condition that can break the build.
…orSync Ensure we generate version prop before sync parallel build
…#31009) For .NET Core 2.0, I ported the ThreadPool's work-stealing implementation to ConcurrentBag, leading to significant performance throughput and allocation improvements. However, there's a subtle difference in the concurrency guarantees the ThreadPool's implementation provided from what ConcurrentBag needs, which ends up breaking certain usage patterns on top of ConcurrentBag. Specifically, ThreadPool's "steal" implementation need not be fully linearizable. It's possible for a thread to see the bag's count as 1, and then while the thread is doing a take/steal for its count to never drop below 1, but for the steal to still fail, even though there was always an item available. This is ok for the thread pool because it manages a known count of work items in the queues separately, and if it sees that there are still items available after a steal has failed, it'll try again. That "try again" logic provided above the work-stealing queue thus didn't make it over to ConcurrentBag, which breaks some usages of ConcurrentBag, in particular cases where a type like BlockingCollection is wrapping the bag and managing its own count. It's possible now for BlockingCollection to know that there's an item in the bag but to then fail to take it, which causes problems such as exceptions being thrown. The fix is to port back the relevant portion of ConcurrentBag from .NET Core 1.x / .NET Framework, where local push operations on a list track the number of times the list transitions from empty to non-empty. A steal operation then looks at those counts prior to doing the steal, and if the steal fails, it looks again after: if the count has increased, it retries. This unfortunately means that local pushes on small lists are now more expensive than in .NET Core 2.0/2.1, as if there are <= 2 items in the list, it takes the lock, but this seems unavoidable given the work-stealing design.
|
I resolved the merge conflict and pushed the changes. |
The TraversalBuildDependsOn gets other things added to it like BuildAllProjects which we don't want for the Sync target so factoring out the common pre-steps and sharing just those with sync and build.
…orSync Fix Sync targets to not actually cause a build to occur as well
|
This pull request has been updated. This PR merges commits made on release/2.1 by the following committers:
|
dotnet-maestro-bot
force-pushed
the
merge/release/2.1-to-release/2.2
branch
from
a1a7f63 to
b61c8bd
Compare
|
@natemcmaster After a new change came in it seems to have undone my merge which resolved the conflicts. Is that intentional? |
|
Yes, that was intentional. The bot doesn't attempt to do anything about merge conflicts. When it opens the PR, it simply makes a snapshot of release/2.1 on |
We should rethink that a little. We need time for conflicts to be resolved and CI to complete without having to worry about our manual changes getting overwritten. |
…dotnet#31009)" (dotnet#31132) This reverts commit b6be5d7.
|
This pull request has been updated. This PR merges commits made on release/2.1 by the following committers:
|
dotnet-maestro-bot
force-pushed
the
merge/release/2.1-to-release/2.2
branch
from
8f8836e to
778a21f
Compare
|
@weshaggard when new commits are pushed to release/2.1 and this PR is still open, what would you like the bot to do instead? Start creating more PRs? Attempt to do some merging automatically within the PR? Ignore? |
|
cc @dagood who had done some work in this space for our version update. If possible we should just replay the new commits on top, but if that doesn't work for some whatever reason just adding a comment to this PR stating that more changes are available (perhaps listing them) but you cannot merge them due to the manual commit. Then we either need to wait for another trigger to get them or somehow manually trigger the new commits. While looking at these it has occurred to me that we are going to constantly hit merge conflicts with the version dependency file as soon as we turn on dependency updating into this new branch. We are likely going to need to figure out a good strategy to handle them that doesn't require manual merge everytime. |
|
aspnet also runs into frequent conflicts on versions files. We've been kicking around some ideas to implement better automerging tooling aspnet/BuildTools#707 |
The way this is handled for VersionTools PRs is it detects if it's the one that made the I haven't thought about the merge case specifically, though... biggest difference is that version update PRs are always a single commit long, so they're simpler. |
15 participants
I detected changes in the release/2.1 branch which have not been merged yet to release/2.2.
I'm a robot and am configured to help you automatically keep release/2.2 up to date, so
I've opened this PR.
This PR merges commits made on release/2.1 by the following committers:
Instructions for merging
This PR will not be auto-merged. When pull request checks pass, please complete this PR
by creating a merge commit, not a squash or rebase commit.
You can also do this on command line:
Please contact ASP.NET Core Engineering if you have questions or issues.
Also, if this PR was generated incorrectly, help us fix it. See https://github.com/aspnet/BuildTools/blob/master/scripts/GitHubMergeBranches.ps1.