Code Monkey home page Code Monkey logo

arcade-services's Introduction

dotnet/dotnet - Home of the .NET VMR

This repository is a Virtual Monolithic Repository (VMR) which includes all the source code and infrastructure needed to build the .NET SDK.

What this means:

  • Monolithic - a join of multiple repositories that make up the whole product, such as dotnet/runtime or dotnet/sdk.
  • Virtual - a mirror (not replacement) of product repos where sources from those repositories are synchronized into.

In the VMR, you can find:

Just like the development repositories, the VMR will have a release branch for every feature band (e.g. release/8.0.1xx). Similarly, VMR's main branch will follow main branches of product repositories (see Synchronization Based on Declared Dependencies).

More in-depth documentation about the VMR can be found in VMR Design And Operation. See also dotnet/source-build for more information about our whole-product source-build.

Goals

  • The main purpose of the dotnet/dotnet repository is to have all source code necessary to build the .NET product available in one repository and identified by a single commit.
  • The VMR also aims to become the place from which we release and service future versions of .NET to reduce the complexity of the product construction process. This should allow our partners and and 3rd parties to easily build, test and modify .NET using their custom infrastructure as well as make the process available to the community.
  • Lastly, we hope to solve other problems that the current multi-repo setup brings:
    • Enable the standard down-/up-stream open-source model.
    • Fulfill requirements of .NET distro builders such as RedHat or Canonical to natively include .NET in their distribution repositories.
    • Simplify scenarios such as client-run testing of bug fixes and improvements. The build should work in an offline environment too for certain platforms.
    • Enable developers to make and test changes spanning multiple repositories.
    • More efficient pipeline for security fixes during the CVE pre-disclosure process.

We will achieve these goals while keeping active coding work in the separate repos where it happens today. For example: ASP.NET features will continue to be developed in dotnet/aspnetcore and CLR features will be continue to be developed in dotnet/runtime. Each of these repos have their own distinct communities and processes, and aggregating development into a true mono-repo would work against that. Hence, the "virtual" monolithic repo: the VMR gives us the simplicity of a mono-repo for building and servicing the product, while active development of components of that product stays in its various existing repos. The day to day experience for typical contributors will not change.

Limitations

This is a work-in-progress. There are considerable limitations to what is possible at the moment. For an extensive list of current limitations, please see Temporary Mechanics.
See the Unified Build roadmap for more details.

Supported platforms

  • 8.0
    • source-build configuration on Linux
  • 9.0+ (WIP)
    • source-build configuration on Linux
    • non-source-build configuration on Linux, Mac, and Windows

For the latest information about Source-Build support for new .NET versions, please check our GitHub Discussions page for announcements.

Code flow

For the time being, the source code only flows one way - from the development repos into the VMR. More details on this process:

We expect the code flow to start working both ways in the .NET 9 timeframe. See the Unified Build roadmap for more details.

Contribution

At this time, the VMR will not accept any changes and is a read-only mirror of the development repositories only. Please, make the changes in the respective development repositories (e.g., dotnet/runtime or dotnet/sdk) and they will get synchronized into the VMR automatically.

Dev instructions

Please note that this repository is a work-in-progress and there are some usability issues connected to this. These can be nuisances such as some checked-in files getting modified by the build itself and similar. For the latest information about Source-Build support, please watch for announcements posted on our GitHub Discussions page.

Prerequisites

The dependencies for building can be found here. In case you don't want to / cannot prepare your environment per the requirements, consider using Docker.

Building

  1. Clone the repository

    git clone https://github.com/dotnet/dotnet dotnet-dotnet
    cd dotnet-dotnet
  2. Build the .NET SDK

    Choose one of the following build modes:

    • Microsoft based build

      For Unix:

      ./build.sh --clean-while-building

      For Windows:

      .\build.cmd -cleanWhileBuilding
    • Building from source

      # Prep the source to build on your distro.
      # This downloads a .NET SDK and a number of .NET packages needed to build .NET from source.
      ./prep-source-build.sh
      
      # Build the .NET SDK
      ./build.sh -sb --clean-while-building

    The resulting SDK is placed at artifacts/assets/Release/dotnet-sdk-9.0.100-[your-RID].tar.gz (for Unix) or artifacts/assets/Release/dotnet-sdk-9.0.100-[your-RID].zip (for Windows).

  3. (Optional) Unpack and install the .NET SDK

    For Unix:

    mkdir -p $HOME/dotnet
    tar zxf artifacts/assets/Release/dotnet-sdk-9.0.100-[your-RID].tar.gz -C $HOME/dotnet
    ln -s $HOME/dotnet/dotnet /usr/bin/dotnet

    For Windows:

    mkdir %userprofile%\dotnet
    tar -xf artifacts/assets/Release/dotnet-sdk-9.0.100-[your RID].zip -C %userprofile%\dotnet
    set "PATH=%userprofile%\dotnet;%PATH%"

    To test your built SDK, run the following:

    dotnet --info

Note

Run ./build.sh --help (for Unix) or .\build.cmd -help (for Windows) to see more information about supported build options.

Building using Docker

You can also build the repository using a Docker image which has the required prerequisites inside. The example below creates a Docker volume named vmr and clones and builds the VMR there.

docker run --rm -it -v vmr:/vmr -w /vmr mcr.microsoft.com/dotnet-buildtools/prereqs:centos-stream8
git clone https://github.com/dotnet/dotnet .

# - Microsoft based build
./build.sh --clean-while-building

# - Building from source
./prep-source-build.sh && ./build.sh -sb --clean-while-building

mkdir -p $HOME/.dotnet
tar -zxf artifacts/assets/Release/dotnet-sdk-9.0.100-centos.8-x64.tar.gz -C $HOME/.dotnet
ln -s $HOME/.dotnet/dotnet /usr/bin/dotnet

Codespaces

You can also utilize GitHub Codespaces where you can find preset containers in this repository.

Building from released sources

You can also build from sources (and not from a context of a git repository), such as the ones you can acquire from a dotnet/dotnet release. In this case, you need to provide additional information which includes the original repository and commit hash the code was built from so that the SDK can provide a better debugging experience (think the Step into.. functionality). Usually, this means the dotnet/dotnet repository together with the commit the release tag is connected to.

In practice, this means that when calling the main build script, you need to provide additional arguments when building outside of a context of a git repository.
Alternatively, you can also provide a manifest file where this information can be read from. This file (release.json) can be found attached with the dotnet/dotnet release.

Synchronizing code into the VMR

Sometimes you want to make a change in a repository and test that change in the VMR. You could of course make the change in the VMR directly (locally, as the VMR is read-only for now) but in case it's already available in your repository, you can synchronize it into the VMR (again locally).

To do this, you can either start a dotnet/dotnet Codespace - you will see instructions right after it starts. Alternatively, you can clone the repository locally and use the vmr-sync.sh or vmr-sync.ps1 script to pull your changes in. Please refer to the documentation in the script for more details.

List of components

The full list of components synchronized into the VMR is here (Components.md).

The repository also contains a JSON manifest listing all components in a machine-readable format.

Filing Issues

This repo does not accept issues as of now. Please file issues to the appropriate development repos. For issues with the VMR itself, please use the source-build repository.

Useful Links

.NET Foundation

.NET Runtime is a .NET Foundation project.

License

.NET is licensed under the MIT license.

arcade-services's People

Contributors

alexperovich avatar alitzelmendez avatar andriipatsula avatar chadnedzlek avatar chcosta avatar crummel avatar dependabot[bot] avatar dkurepa avatar dotnet-maestro-bot avatar dotnet-maestro[bot] avatar dougbu avatar epananth avatar garath avatar jcagme avatar johntortugo avatar jonfortescue avatar lukas-lansky avatar lwintjen avatar mattgal avatar meganaquinn avatar michellemcdaniel avatar milenahristova avatar missymessa avatar mmitche avatar oleksandr-didyk avatar premun avatar riarenas avatar rokonec avatar russkie avatar sunandabalu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

arcade-services's Issues

[darc/maestro++] Maestro should synchronize version update branch when pushing new updates

When pushing new updates to a PR, Maestro/DarcLib should update the PR branch with the target branch (if possible). While GitHub/AzDO will do this when creating the merge branch, if a user has to make modifications on top of the PR branch, they will likely download and modify an out of date branch. Typically this would happen when an update causes a failure which sits for a few days.

[darc/maestro++] Support removing repo merge policies

@dougbu commented on Wed Jul 03 2019

Currently the only darc commands related to repository policies are get-repository-policies and set-repository-policies. While that covers CRU because set-repository-policies both creates and updates (well, overwrites) policies, there is no command to delete repo policies.

For example, we have old policies for non-existent branches that won't be serviced. They just add noise to darc get-repository-policies --all output. I know --all isn't the default but it's very useful when creating policies for branches that don't yet exist.

For example

darc get-repository-policies --repo https://github.com/aspnet/Extensions --all
https://github.com/aspnet/Extensions @ master
- Merge Policies:
  Standard
https://github.com/aspnet/Extensions @ release/3.0-preview3
- Merge Policies:
  Standard
https://github.com/aspnet/Extensions @ release/3.0-preview4
- Merge Policies:
  Standard
https://github.com/aspnet/Extensions @ release/3.0-preview5
- Merge Policies:
  Standard
https://github.com/aspnet/Extensions @ release/3.0-preview53
- Merge Policies:
  Standard
https://github.com/aspnet/Extensions @ release/3.0-preview6
- Merge Policies:
  Standard
https://github.com/aspnet/Extensions @ release/3.0-preview7
- Merge Policies:
  Standard

Hmm, that output includes policies for a branch that never existed. The 'release/3.0-preview53' repo policies must have been accidentally created (probably by me โ˜น๏ธ).

ValidateSdk missing Build.binlog

Binlog file is actually produced but before we start the official part of the build we copy the outputs to a validatesdk folder in the artifacts folder which we are not copying.

We need to copy eng/common/templates/job/job.yml into a location outside eng/common so no other repos are affected by this change and add a task similar to https://github.com/dotnet/arcade/blob/6f33f02efeafb578b3f99da08cb2670e0470c917/eng/common/templates/job/job.yml#L162 but updating PathtoPublish and ArtifactName

Since ValidateSdk only runs in official builds the task we will add should just run in official builds

[darc/maestro++] Use JSON as the output format

Currently Darc outputs the results of some commands in YAML. There has been several request, including build from source, to change the output to JSON.

FYI: @mmitche @chcosta @crummel

Rough stab at what could easily-ish be supported by json:

  • add-channel
  • add-subscription
  • add-build-to-channel
  • delete-build-from-channel
  • gather-drop
  • get-asset
  • get-build
  • get-channels
  • get-default-channels
  • get-dependencies
  • get-dependency-graph
  • get-health
  • get-latest-build
  • get-repository-policies
  • get-subscriptions
  • set-repository-policies
  • update-build
  • update-subscription
  • get-goal

[darc/maestro++] Improve darc gather-drop's dry run

The dry run ability today stops just short of downloading files. Location information is verified, but not much else. Dry run should be improved so:

  • It checks the file exists and is accessible (this also means dealing with credentials)
  • It checks downloading the file would not overwrite existing files (unless --overwrite is specified)
  • We can baseline away dependencies we expect not to be able to find builds for (e.g. pinned version of xdt)

[darc/maestro++] Dependency update + add handling should be generic and consistent

The update and add dependencies operations on the git file manager use different handling for:

  • Adding (uses new updaters, but these can't be used for update)
  • Updating (uses special handling for global.json, but not the generic known updater function)
  • Script files are handled at the Remote level rather than the file manager level.

This should be consistent.

In addition, this is a good time to change how we specify 'well known' types. These should be able to be specified in the Version.details.xml file. So darc would read that and choose an updater based on the type. The default should be Versions.props.

[darc/maestro++] Default channel update

Add an API which allows for a default channel to be updated, rather than having to delete and recreate the default channel.

The basic rule is that a channel may only be produced from one branch, so updating or adding a default channel association where the channel was previously produced from another branch should update the existing entry.

[darc/maestro++] Visual picture of dependency graph and flow that highlights when/where maestro is backing up

/cc @davidfowl @Chrisboh @mmitche

We have the data for this along with A visual representation, but the context here is a quick glance picture that highlights problems in order to expedite investigation into issues. Think of a screen in a room that is always showing the state of maestro flow and flashes red when something needs attention. This is something I've had in my head, but also got a similar request from David Fowler this morning. Since we have an explicit customer ask for this, I'd like to start with someone reaching out to him and understanding the exact use case and details.

David, please feel free to add/correct anything I have in here.

ToolsError build failures in 'official/dotnet/arcade-services/refs/heads/master' - '20190315.5'

@dotnet-mc-bot commented on Sat Mar 16 2019

There were a set of failures during this build. Here is a summary of these:

@robertborr


@robertborr commented on Mon Mar 18 2019

The build timed out - you may wish to allocate more time.

F:\workspace_work\1\s.dotnet\sdk\2.1.504\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(129,5): error MSB4220: Waiting for the currently executing task "GenerateDepsFile" to cancel. [F:\workspace_work\1\s\src\Maestro\SubscriptionActorService\SubscriptionActorService.csproj]
F:\workspace_work\1\s.dotnet\sdk\2.1.504\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(129,5): error MSB4220: Waiting for the currently executing task "GenerateDepsFile" to cancel. [F:\workspace_work\1\s\src\Maestro\SubscriptionActorService\SubscriptionActorService.csproj]
##[error]The operation was canceled.

[darc/maestro++] Support repo-wide merge policies

@dougbu commented on Wed Jul 03 2019

Today, "repository merge policies" are actually branch-specific. At least for ASP.NET Core, we have no reason to vary the policies per-branch. Suggest making the --branch option of the darc set-repository-policies command optional. If that can't be done for some reason, fall back to supporting branch wildcards e.g. (for our case) --branch *.

For example,

darc get-repository-policies --repo aspnet/asp

does not list a repo policy set that I just added using

darc set-repository-policies --repo https://github.com/aspnet/AspNetCore --all-checks-passed --no-requested-changes --quiet --ignore-checks AspNetCore-helix-test, license/cla --branch *

I suspect this means the --branch * policy set will match no branch instead of all.

[darc/maestro++] Add `--regex` option to `darc get-repository-policies`

@dougbu commented on Wed Jul 03 2019

darc get-repository-policies lacks options that could / should be copied over from darc get-subscriptions. The one I miss the most is --regex. --exact is also applicable but I've never needed that one.

For example, the following command displays information about policies in AspNetCore-Tooling as well as the hoped-for AspNetCore information

darc get-repository-policies --repo https://github.com/aspnet/AspNetCore --branch master

Patch `dotnet symbol-tool` to check completeness & availability of symbols

After some review / discussions about these issues: dotnet/arcade#167, dotnet/arcade#173, dotnet/arcade#1874 it was clear that issue dotnet/arcade#1874 encompasses both dotnet/arcade#167 and dotnet/arcade#173. Moreover, it was decided that we would use symbol-tool to perform validation and availability check of symbols.

A temporary solution for both of these problems was provided in this PR: dotnet/arcade#2492 . However, there are a few things that the script in that PR intentionally doesn't do and that we should make sure symbol tool does. Moreover, there are a few things we should implement in symbol tool as well:

  • Receive the path to two local NuGet packages and perform symbol completeness check.
  • Receive the path to a regular NuGet package and check if symbols for that package are available in both MSDL & SymWeb.
  • No need for downloading files when performing availability. Just checking the symbol file is available is probably sufficient.
  • The tool should be able to handle "extension-less" files, like Linux executables.
  • Make the tool available as an MSBuild task/target ?

For the record:

  • Symbol availability: check that for every module in a .nupkg there is a symbol file in MSDL orand SymWeb.
  • Symbol completeness: given a .nupkg and a .symbols.nupkg (or .snupkg) we need to check that for each module in the .nupkg there is a symbol file in the symbol package.

/cc @mikem8361 @dagood @tmat @leculver

[darc/maestro++] Add reviewers to Maestro-generated pull request

When Maestro creates a PR, the only reviewers added are the default ones in the target repo (like CODEOWNERS in github, for example).

This has a couple drawbacks:

  1. This puts the burden of PR approval on the target repo owners.
  2. These PR's are not visible to the product owners, unless they are explicitly watching these repos

Therefore, it would be nice if Maestro could add reviewers when the PR is created.

This work probably requires two parts:

  1. The ability to add/update/delete reviewers from an already existing subscription id in DARC
    (nice to have would be the ability to add the reviewers when creating the subscription as well, but this is more work and is not a blocker)
  2. The ability for Maestro to add these reviewers when creating a PR

This needs to work in both github and AzDO.

[darc/maestro++] Maestro should always be able to auto-merge update PRs

Because Maestro is an app today, it only has R/W permissions to repos. If a repository has required reviewers on the repo or has restricted the users who can push to a branch, it is unable to merge automatically. Find a way to enable auto-merging even in these cases. Some ideas:

  • Use a bot account rather than an app (bot account would need to be admin)
  • Convince github to add permissions to an app so it can merge around policy

[darc/maestro++] Darc should be buildable from source

I noticed issues about using Octokit #2580 and VSTS C# libs #2579 in Darc. This sounds like a great idea, but I want to make sure it's implemented in a way that leaves Darc able to build from source.

If Octokit and VSTS APIs can build from source, ok, but it would be preferable not to build them at all. The builds take time, and the capabilities won't be used in source-build.

/cc @alexperovich @jcagme


I haven't looked into every one, but these are unknowns when it comes to source-build:

An easy way I see to do this is to split code that needs to use these dependencies into separate csproj's, condition the dependency, and condition some small part of the code to link in (or not) web client capability. (Microsoft.DotNet.Maestro.Client is an example of something that's already split off!) The property ExcludeFromSourceBuild is used to skip a project during source-build.

I can imagine something fancier being done, where there's a real extensibility point on Darc. The user could choose to download some extra packages (or something) to enable web client capabilities.

[darc/maestro++] "darc add" should use existing Versions.props propertygroup

If you add a dependency to a repo using darc add...

> darc add -n Microsoft.DotNet.PlatformAbstractions -t toolset -r https://github.com/dotnet/core-setup

... it creates an entry in $(RepositoryEngineeringDir)Versions.props...

<PropertyGroup>
  ...
  <MicrosoftDotNetPlatformAbstractionsVersion></MicrosoftDotNetPlatformAbstractionsVersion>
</PropertyGroup>

If the repo already had an entry, there are now two entries, with the latter entry being empty...

<PropertyGroup>
  <MicrosoftDotNetPlatformAbstractionsVersion>2.1.0</MicrosoftDotNetPlatformAbstractionsVersion>
  ...
  <MicrosoftDotNetPlatformAbstractionsVersion></MicrosoftDotNetPlatformAbstractionsVersion>
</PropertyGroup>

Now, when you run darc update-dependencies, you will always update the first entry but the value will resolve as empty (no version) because of the second entry.

Uberclone: Fetch on failing checkout does not work

Appears to be a bug introduced with the long path fix - the exception for the commit not being found is being treated as a long path exception. Consequently, we never try to fetch new commits.

Workaround: delete the "master" copy of the repos (.git/modules in source-build). Then everything will be recloned and you'll get all the commits.

Assigning to myself so I fix this properly.

Move Feed targets logic into the Arcade SDK

dotnet/arcade#1908 (comment)

if you move all targets logic to Publish.proj and only expose tasks from the package you'll have to define and maintain only the tasks API. It this thus going to be simpler.
I agree that the current state is not desirable. I'd suggest that instead of importing the targets file defined in package here we actually remove it from the package and move all the logic here.

[darc/maestro++] LibGit2Sharp uses native binaries that don't have BuildID

Some of our arcade-services libraries use LibGit2Sharp which in turn uses a package called LibGit2Sharp.NativeBinaries which contains some *.so files that don't have a BuildID note (see example here) in them. This causes our symbol uploader to fail for those arcade-services packages.

We need to figure out what's the right thing moving forward here. Whether it is patching microsoft.symboluploader.build.task to not fail in such cases or something else.

@mikem8361 @dagood @markwilkie

[darc/maestro++] dependency flow: how to deprecating a package ID?

This is a fairly common scenario for dev work, and I don't see a way to do this with darc yet. With my understanding of the current design, the Maestro bot will leave behind stale references to deprecated packages when either of these scenarios occur. In ProdCon v1, we had a protection against this -- a strict check on incoming version variables -- which helped us know when packages were dropped or renamed. Unless I've missed something, I don't see a replacement for this in darc/maestro.

Scenario A - renaming a package on a channel

Team A was producing previews of System.Banana and pushing to channel ".NET Core Dev", but decides they would rather ship this as System.Strawberry. Consumers of need to update to the new package ID.

Scenario B - deleting a package from a channel

Team A was producing previews of System.Titanic, but due to reasons, has decided this package should not ship (pun intended). Consumers should stop using this package as it will not have a production release.

Questions

  • Is there a way to make a package as 'deprecated'?
  • Is there a way to remove a package entirely from a channel?
  • Does maestro provide {notification, errors, warnings} when it cannot find update information for a package listed in Version.Details.xml/Versions.props? If not, should it?

cc @markwilkie @jcagme

[darc/maestro++] darc doesn't use Arcade CLI

It looks, cursorily, like darc makes use of whatever dotnet is on the machine.

D:\demo\hello-demo>darc
A fatal error occurred, the required library hostfxr.dll could not be found.
If this is a self-contained application, that library should exist in [C:\Users\chcosta\.dotnet\tools\.store\microsoft.dotnet.darc\1.0.0-beta.18517.1\microsoft.dotnet.darc\1.0.0-beta.18517.1\tools\netcoreapp2.1\any\].
If this is a framework-dependent application, install the runtime in the default location [C:\Program Files\dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location.

Arcade is supposed to be fully bootstrappable, and installs a local copy of the cli under the .\.dotnet\ folder. Yes, Arcade will actually use the machine wide install of the CLI if available, but I think there's lots of scenarios where a dev might not have / want one of those. This is useful...

If this is a framework-dependent application, install the runtime in the default location [C:\Program Files\dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location.

โ€ฆ but it would be nice if, on a clean machine (with no cli installed machine-wide), if you just restored darc and it started working.

FYI @mmitche @jcagme

Darc fails to find Version.Details.xml in a submodule

It looks like this is because Darc assumes that the parent of the .git directory is always the root of a submodule: https://github.com/dotnet/arcade-services/blob/master/src/Microsoft.DotNet.Darc/src/DarcLib/Actions/Local.cs#L27 and https://github.com/dotnet/arcade-services/blob/master/src/Microsoft.DotNet.Darc/src/DarcLib/Helpers/LocalHelpers.cs#L45

I think Darc should be doing git rev-parse --show-toplevel in order to get the root of the Git repo.

Repro steps:

git clone https://github.com/dotnet/source-build
git submodule update --init
cd src/core-sdk
dotnet Microsoft.DotNet.Darc.dll get-dependency-graph

Expected results: Get the dependency graph based on core-sdk's Version.Details.xml.
Actual results:

Getting root dependencies from local repository...
info: Microsoft.DotNet.Darc.Operations.Operation[0]
      Getting a collection of dependencies from 'eng/Version.Details.xml' in repo '/home/chris/dotnet_source-build/.git/modules/src'...
info: Microsoft.DotNet.Darc.Operations.Operation[0]
      Reading 'eng/Version.Details.xml' in repo '/home/chris/dotnet_source-build/.git/modules/src' and branch ''...
fail: Microsoft.DotNet.Darc.Operations.Operation[0]
      Something failed while getting the dependency graph.
System.IO.DirectoryNotFoundException: Could not find a part of the path '/home/chris/dotnet_source-build/.git/modules/src/eng/Version.Details.xml'.
   at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at System.IO.StreamReader..ctor(String path, Encoding encoding, Boolean detectEncodingFromByteOrderMarks, Int32 bufferSize)
   at Microsoft.DotNet.DarcLib.LocalGitClient.GetFileContentsAsync(String relativeFilePath, String repoUri, String branch) in /home/chris/dotnet_source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/LocalGitClient.cs:line 58
   at Microsoft.DotNet.DarcLib.GitFileManager.ReadXmlFileAsync(String filePath, String repoUri, String branch) in /home/chris/dotnet_source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/Helpers/GitFileManager.cs:line 412
   at Microsoft.DotNet.DarcLib.GitFileManager.ReadVersionDetailsXmlAsync(String repoUri, String branch) in /home/chris/dotnet_source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/Helpers/GitFileManager.cs:line 37
   at Microsoft.DotNet.DarcLib.GitFileManager.ParseVersionDetailsXmlAsync(String repoUri, String branch, Boolean includePinned) in /home/chris/dotnet_source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/Helpers/GitFileManager.cs:line 84
   at Microsoft.DotNet.DarcLib.Local.GetDependenciesAsync(String name, Boolean includePinned) in /home/chris/dotnet_source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/DarcLib/Actions/Local.cs:line 114
   at Microsoft.DotNet.Darc.Operations.GetDependencyGraphOperation.ExecuteAsync() in /home/chris/dotnet_source-build/tools-local/arcade-services/src/Microsoft.DotNet.Darc/src/Darc/Operations/GetDependencyGraphOperation.cs:line 73

[darc/maestro++] Make merge policies source clear in `darc` output

@dougbu commented on Wed Jul 03 2019

darc get-subscriptions confusingly shows non-empty policies for batchable subscriptions. If this command is going to display repository policies, it should be clear the policies aren't actually part of the subscription definition. An alternative would be to show no policies or (perhaps best) to display just an indication that repo policies exist for the target branch.

For example,

darc get-subscriptions --target-repo https://github.com/aspnet/AspNetCore$ --regex --target-branch master --channel '.NET Tools - Latest'
https://github.com/dotnet/arcade (.NET Tools - Latest) ==> 'https://github.com/aspnet/AspNetCore' ('master')
  - Id: 4409590c-0c9e-4f51-7dbf-08d6ba16a224
  - Update Frequency: EveryWeek
  - Enabled: True
  - Batchable: True
  - Merge Policies:
    AllChecksSuccessful
      ignoreChecks =
                       [
                         "AspNetCore-helix-test",
                         "license/cla"
                       ]
    NoRequestedChanges
darc get-repository-policies --repo aspnet/AspNetCore --branch master
https://github.com/aspnet/AspNetCore @ master
- Merge Policies:
  AllChecksSuccessful
    ignoreChecks =
                   [
                     "AspNetCore-helix-test",
                     "license/cla"
                   ]
  NoRequestedChanges
https://github.com/aspnet/AspNetCore-Tooling @ master
- Merge Policies:
  Standard

@garath commented on Thu Jul 11 2019

@mmitche @jcagme Where's the best place to track this?


@mmitche commented on Thu Jul 11 2019

I this repo is fine. Need to create a p8 or GA epic for dependency flow to put this in.

[darc/maestro++] Public/anonymous BAR access

Is this planned? For example, anonymously seeing the latest core-setup build with this URL:

https://maestro-prod.westus2.cloudapp.azure.com/api/builds/latest?repository=https%3A%2F%2Fgithub.com%2Fdotnet%2Fcore-setup&api-version=2018-07-16

Right now, I get a 401 anonymously, and the results I want if I provide my auth.

In particular, Tizen builds used to be triggered by changes on dotnet/versions. How can we accomplish the same with BAR with dotnet/versions publishing turned off?

@markwilkie @mmitche

Publishing/Dependency Flow is Complete

Issues that are not a current business priority, but are still worth considering for publishing and dependency flow infrastructure.

Recently Triaged Issues

All issues in this section should be triaged by the v-team into one of their business objectives or features.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.