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
[build] Use arcade dependency management tooling #5731
Conversation
0c3e346
to
199668b
Compare
199668b
to
3cdddc9
Compare
9a15982
to
38d83e3
Compare
@@ -0,0 +1,12 @@ | |||
<Dependencies> |
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.
I think @jonpryor wasn't thrilled about a new eng
folder.
Is there any way to put these in build-tools
? If not, we probably have to put them here.
dotnet/maui already has an eng
folder, so it will be fine.
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.
I haven't found a way to provide alternate paths for files to darc
, so unless we find the source and PR into that tool to check multiple paths we'll have to keep the eng
folder.
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.
There is this $(RepositoryEngineeringDir)
:
But if we put our own value for $(RepositoryEngineeringDir)
in Directory.Build.props
, I don't know if the tooling would know to parse that value and use the correct value for $(RepositoryEngineeringDir)
.
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.
I think we'd need to PR something here (and perhaps elsewhere) - https://github.com/dotnet/arcade-services/blob/bb98f0d13ac51eb81131b5ef382ada12fd84e8e0/src/Microsoft.DotNet.Darc/src/DarcLib/Helpers/VersionFiles.cs#L16
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.
Otherwise, this looks great. I like how we don't have to lookup & hardcode the runtime packs version anymore.
Context: https://github.com/dotnet/arcade/blob/ea609b8e036359934332480de9336d98fcbb3f91/Documentation/Darc.md
The dotnet core engineering group has some dependency management tooling
(known as
darc
) that we'd like to adopt. Integrating this tooling into the build system will make it easier to stay up to date with the
latest .NET 6 SDK changes.
Many dotnet repos use a publishing workflow that will push build
artifact data to a central location known as the "Build Asset Registry".
This data includes a "Channel" association, which is the key to
dependency updating. Local updates and automatic update "Subscriptions"
compare the version files in a given repo against the product versions
avalable in the channel that you are interested in.
We hope to be able to publish Xamarin SDK build information to this
central registry in the near future, so that other products can take a
dependency on us as needed (MAUI for instance).
The
darc
tool looks for four different files in a repo when adding adependency or when checking for an update:
Both of the
Version
files present in theeng
folder are updated whena new dependency is available.
To work with
darc
locally you'll need to install the global tool, jointhe
arcade-contrib
GitHub team, and configure your auth settings.To add a new dependency, use the
darc add-dependency
command:To update all dependencies, use the
darc update-dependencies
command:
To configure automatic updates, use the
darc add-subscription
command to enroll a target repo/branch into updates from a particular
channel:
Once a subscription is configured, a pull request will be created
automatically by the dotnet Maestro bot when dependency updates are
available.
This PR also contains a bump to .NET 6.0.100-preview.3.21168.18.
Changes: dotnet/installer@19e22a7...823c1df
The .NET 6 .apkdesc files have been updated accordingly. It seems that
System.Private.CoreLib.dll
grew in size, however reductions in nativelibraries and other files results in overall smaller package sizes.
Simple XA:
XF/XA: