dotnet / versions

This repo contains information about the various component versions that ship with .NET Core.

.NET Versions

This repo contains basic information about:

• Docker images produced by the .NET team
• Docker images produced by the Go team
• Legacy latest build information for releases 2.1 and prior.

versions's Issues

Add a test for Maestro

To ensure subscription.json changes are well-formatted and won't break all the other subscriptions.

Add a way to pass dotnet/versions commit hash into the triggered VSTS build

This can be used by the triggered def to make sure each file change is only processed once. Right now, if two changes come in quickly, both triggered builds will see the same latest dotnet/versions state. If the builds know the dotnet/versions commits that triggered them, they can be sure sure they're the only build triggered for that specific commit.

Release 2.1's Host etc link is broken

https://github.com/dotnet/versions/tree/master/build-info/dotnet/product/cli/release/2.1

Add "**" pattern trigger path handling

Right now Maestro supports an ending **/* explicitly, but not foo/**/bar or more complicated glob patterns. For orchestrated build final publish, we might want to trigger on dotnet/product/**/build.semaphore, for example.

Default approach is to add explicit ** support.

Another way is to let the subscription define a trigger regex rather than just glob matching. We can do both, eventually: better glob matching and regex support.

Azure 2.1.1 Runtime

When will the .NET Core 2.1 .1 Runtime be available in Azure?

Add a Jenkins build handler

Right now Maestro can only queue VSTS builds. This is not a good situation for builds that happen completely in Jenkins See the discussion in https://github.com/dotnet/core-setup/issues/1566 about how to orchestrate Samsung builds along with Microsoft ones.

The current workaround is an "adapter" VSTS build definition to trigger a Jenkins build. (This hasn't been attempted yet.)

dotnet build-info unmaintained?

/build-info/dotnet hasn't been updated in three years, so I'm wondering where we can get the current version information for a given channel?
For example, what is the source of the product commit information for the dotnet/installer table?
https://github.com/dotnet/installer?tab=readme-ov-file#use-dotnet---help-to-see-available-commands-or-visit-httpsakamsdotnet-cli

Add "triggerRepository" property that doesn't require files to change

In Core-Setup CLI, a commit is required before running a new build. Sometimes a simple retry is desired, so we need to make a dummy commit. The cleanest possible dummy commit is one that changes no files, which means Maestro currently can't detect it and trigger the build. Adding a feature to run an action even if no files changed would allow us to use no-op dummy commits.

Add a test that ensures "triggerPaths" are well-formed and correct

When someone creates a new subscription, they have to build up a URL for the trigger paths. However, it is easy to get these URLs wrong. See #127.

We should have a test that checks the triggerPath URLs are well-formed and will actually work.

dotnet publish -r linux-x64 returns warning NU1603 after added feed manually

Repro Steps:

1. Install sdk 2.1.403-servicing-009266 under 2.1 branch

2. dotnet new console

3. Manually adding feed  

4. dotnet publish -r linux-x64

Expected Result:
dotnet publish works fine

Actual Result:
Returns warning NU1603

Dotnet --info
.NET Core SDK (reflecting any global.json):
Version: 2.1.403-servicing-009266
Commit: 6498f0b0d4

Runtime Environment:
OS Name: ubuntu
OS Version: 16.04
OS Platform: Linux
RID: ubuntu.16.04-x64
Base Path: /usr/share/dotnet/sdk/2.1.403-servicing-009266/

Host (useful for support):
Version: 2.1.5-servicing-26910-03
Commit: 2e36154fde

.NET Core SDKs installed:
2.1.403-servicing-009266 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.5-rtm-31004 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.5-rtm-31004 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.5-servicing-26910-03 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

Move Maestro to its own repository

There's no pressing need to do this, but some soft reasons Maestro doesn't fit here:

• Maestro listens to other repos too, not just build-info changes.
• Changes under the Maestro path (typically subscription updates) are independent of build-info changes.
• All changes to build-infos are automated, with the small exception of manual fixups. All changes to Maestro are manual subscription changes.
• Many teams will want to write to and read from build-infos for build coordination, but Maestro is a service.

No concrete plan to make the move--for now, it's waiting for a hard reason.

/cc @naamunds @dleeapho

[dnceng-bot] Branch `versions/main` can't be mirrored to Azdo fast forward branch

Branch main in dotnet/versions repo can't be mirrored from GitHub to Azure DevOps main via fast forward.
There was unexpected error during the mirroring process.

failed to connect to github.com: Connection refused

Problem need to be resolved to unblock the code flow.

You can troubleshoot the issue by:

• checking the logs of the mirroring process in the mirroring pipeline.
• by trying to mirror the branch manually
• you can disable the mirroring of the branch in the configuration file.
• you can ask @dotnet/dnceng for help or read the documentation.

Please close this issue once the problem is resolved.

URL paths for RHEL 7.2 SDK and ASP.NET Core Runtime installer should omit “rhel” on github page - 2.1 master branch

From @yuki233 on March 29, 2018 6:23

URL paths for RHEL 7.2 SDK and ASP.NET Core Runtime installer should omit “rhel” on https://github.com/dotnet/versions/tree/master/build-info/dotnet/product/cli/release/2.1. Otherwise, it will return 404 error.

Workaround: Modify the link **-rhel-x64.rpm -> -x64.rpm,
SDK:
https://dotnetfeed.blob.core.windows.net/orchestrated-release-2-1/20180326-03/final/assets/Sdk/2.1.300-preview2-008407/dotnet-sdk-2.1.300-preview2-008407-**rhel-x64.rpm
->
https://dotnetfeed.blob.core.windows.net/orchestrated-release-2-1/20180326-03/final/assets/Sdk/2.1.300-preview2-008407/dotnet-sdk-2.1.300-preview2-008407**-x64.rpm

ASP.NET Core Runtime:
https://dotnetfeed.blob.core.windows.net/orchestrated-release-2-1/20180326-03/final/assets/aspnetcore/Runtime/2.1.0-preview2-30478/aspnetcore-runtime-2.1.0-preview2-30478-**rhel.7-x64.rpm**
->
https://dotnetfeed.blob.core.windows.net/orchestrated-release-2-1/20180326-03/final/assets/aspnetcore/Runtime/2.1.0-preview2-30478/aspnetcore-runtime-2.1.0-preview2-30478-**x64.rpm**

Copied from original issue: dotnet/cli#8929

Allow @dotnet/dnceng to approve/merge PRs

As every repo will be changing their subscription during the Master-to-Main renaming, we will have a high volume of pull requests to this repo that will need to be approved/merged. Currently, a very limited amount of people have those permissions.

I suggest it would be good to allow the whole @dotnet/dnceng to have these permissions as First Reponders will be the main point of contact for repo owners who go through the renaming.

/cc @mmitche

Add link to aspnetcore-runtime

To successful install dotnet-sdk.deb or rpm, aspnetcore-runtime, Runtime Host, Host FX Resolver ,Shared Framework are required.

Other than aspnetcore-runtime, rest of them are in the list.

Maestro logs that VSTS build queueing was successful even when sign-in failed

Steps to reproduce the issue

1. Run the Maestro WebAPI app without valid VSO credentials (e.g. with the VsoUser and VsoPassword app settings empty).
2. Send an HTTP request to Maestro that represents a commit-pushed event which triggers an action in subscriptions.json and thus attempts to queue a build.

Expected behavior

Maestro logs a message saying that the build was not successfully queued due to invalid credentials.

Actual behavior

Maestro logs "Successfully queued VSO build."

Fix CoreFXGeneralExecutor-Release failures due to CoreFX native build failing

Some dependency updates fail because the CoreFX native build doesn't work:

• https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_build?_a=summary&buildId=206187
• https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_build?_a=summary&buildId=205575
• https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_build?_a=summary&buildId=205170

These dependency updates probably shouldn't be doing a native build at all.

.Net Foundation Contribution License Agreements

Same issue as https://github.com/dotnet/core-setup/issues/42 only for dotnet/versions

We need to add the @dnfclas bot to /dotnet/versions

cc: @BethMassi @martinwoodward @richlander

LKG_Packages are out-of-date

I noticed that for CoreCLR and CoreFx that LKG_Packages are out of date. I'd expect these to have the last shipped stable packages, but instead it looks like they have the first shipped stable packages (EG: RTM, not servicing).

Add a way to force Maestro to run a certain subscription as if its trigger file changed

This would allow easy end-to-end testing of subscriptions.json changes and easy retries when triggered builds fail. The retry target should be a subscription, not a file, to avoid forcing other subscriptions to run unnecessarily.

/cc @MichaelSimons @naamunds

Update download links to point to upgradeable native linux installers

After the work has been completed in https://github.com/dotnet/core-setup/issues/4097, we should update the links in this repo to point to the upgradeable ones.

For example at https://github.com/dotnet/versions/tree/master/build-info/dotnet/product/cli/release/2.1:
https://dotnetfeed.blob.core.windows.net/orchestrated-release-2-1/20180510-02/final/assets/aspnetcore/Runtime/2.1.0-rtm-30765/aspnetcore-runtime-2.1.0-rtm-30765-x64.deb
needs to be changed to
https://dotnetfeed.blob.core.windows.net/orchestrated-release-2-1/20180510-02/final/assets/aspnetcore/Runtime/2.1.0-rtm-30765/aspnetcore-runtime-2.1.0-rtm-30765-x64-upgrade.deb

This will need updates to the core-setup installers as well as the aspnetcore installers and will require changes in the release/2.1 page. The changes have also been made in master/dev but is there a page tracking those builds?

cc @wli3 @livarcocc @natemcmaster @Petermarcu

Disable Maestro for release/uwp6.0

tracking issue for dotnet/corefx#26316 (comment)

Add a list of dotnet/versions maintainers

This would make it clear who can merge and who to ping for reviews. (I am one.)

"/**/*" behavior is unusual, effectively ".*$" rather than "/.*$"

The behavior of /**/* is defined here:

versions/Maestro/src/Microsoft.DotNet.Maestro.WebApi/Models/SubscriptionsModel.cs

Lines 89 to 93 in 1c00f95

	if (path.EndsWith("/**/*", StringComparison.OrdinalIgnoreCase))
	{
	string rootPath = path.Substring(0, path.Length - 5);
	return modifiedFile.FullPath.StartsWith(rootPath, StringComparison.OrdinalIgnoreCase);
	}

This means /**/* matches file changes where the url starts with everything up to the /, exclusive. For example, release/3.0/**/* will match release/3.0/foo/bar but also, unexpectedly, release/3.0.5/foo/bar.

To work around the issue and make the pattern behave as expected, you must instead use //**/*. release/3.0//**/* will match release/3.0/foo/bar but not release/3.0.5/foo/bar.

This could be fixed. subscriptions.json is the only place this behavior is depended on, and it lives in this repo. A complication is is that the service reads subscriptions.json live, from GitHub, but the service must be manually deployed. (The service is deployed extremely rarely.)

---

Note that general glob patterns are not generally supported. /**/* is detected specifically. See #207 proposing more general support, or switching over to regex.

CoreCLR subscription job is failing

It looks like the CoreCLR subscription job has been failing since dotnet/coreclr#22525 was merged with:

Searching for Visual Studio 2017 or later installation
Visual Studio 2017 or later not found
Error: Visual Studio 2017 or 2019 required.
       Please see https://github.com/dotnet/coreclr/blob/master/Documentation/building/windows-instructions.md for build instructions.

It looks like this is likely due to us dropping support for VS2015.

Add link to aspnetcore-runtime

#215

Sorry that I cannot reopen it. But it is missing in the latest 2.1 and 2.1-preview1

Allow triggerPaths to include wildcard for repository name

This would let us avoid listing every aspnet repo individually in #306.

I'd expect changes to be pretty limited to here:

versions/Maestro/src/Microsoft.DotNet.Maestro.WebApi/Models/SubscriptionsModel.cs

Lines 75 to 95 in 93cc2cd

	private IEnumerable<Subscription> GetSubscriptions(ModifiedFileModel modifiedFile)
	{
	return Subscriptions.Where(s => s.TriggerPaths.Any(p => Matches(p, modifiedFile)));
	}
	private bool Matches(string path, ModifiedFileModel modifiedFile)
	{
	bool matches = string.Equals(path, modifiedFile.FullPath, StringComparison.OrdinalIgnoreCase);
	if (matches)
	{
	return true;
	}
	if (path.EndsWith("/**/*", StringComparison.OrdinalIgnoreCase))
	{
	string rootPath = path.Substring(0, path.Length - 5);
	return modifiedFile.FullPath.StartsWith(rootPath, StringComparison.OrdinalIgnoreCase);
	}
	return false;
	}

Maybe it should change to full-blown regex. (Also solving #207.)

/cc @mmitche

Maestro should use a build account user agent for queueing builds

Currently, Maestro queues builds with @eerhardt as the user agent (e.g. https://devdiv.visualstudio.com/DevDiv/_build/explorer?_a=summary&buildId=396022). A build account user agent should be used instead.

No version information found for System.Threading.Tasks.Extensions 4.5.2

I'm using this repository to automatically locate the sources for a set of assemblies (we need to do this in our company for compliance reasons).

However I can't find "System.Threading.Tasks.Extensions 4.5.2" in this repository.

My tool did work fine for "System.Threading.Tasks.Extensions 4.5.1", which can be found in
\build-info\dotnet\corefx\release\2.2\Latest_Packages.txt

So could you please add information for "System.Threading.Tasks.Extensions 4.5.2" to this repository, so that my tool can automatically locate its sources?

Alternatively, could you please tell me which version of the corefx repo does contain version 4.5.2 of that assembly?

Infrastructure

versions/Maestro/subscriptions.json

Line 21 in 54e2135

// A 'build' that merges changes from github into the dnceng intance of Azure DevOps (into internal/ prefixed branches)