Note that usually only the most recent link in each section is interesting. Older links are included for reference only.
The PR build definition can be found here or by navigating through an existing PR.
There is also a duplicate scouting PR build that is identical to the normal PR build except that it uses a different Windows machine queue that always has the next preview build of Visual Studio installed. This is to hopefully get ahead of any breaking API changes. That build definition is here.
Branch auto-merge definitions are specified here.
VS 16.4 to current - part of the build definition. See below.
The following insertion generators are automatically invoked upon successful completion of a signed build in each of their respective branches.
VS 16.0 and prior were done manually
Starting with the 16.4 release and moving forwards, the VS insertion is generated as part of the build. The relevant
bits can be found near the bottom of azure-pipelines.yml
under the VS Insertion
header. The
interesting parameters are componentBranchName
and insertTargetBranch
. In short, when an internal signed build
completes and the name of the branch built exactly equals the value in the componentBranchName
parameter, a component
insertion into VS will be created into the insertTargetBranch
branch. The link to the insertion PR will be found
near the bottom of the build under the title 'Insert into VS'. Examine the log for 'Insert VS Payload' and near the
bottom you'll see a line that looks like Created request #xxxxxx at https://...
.
Insertions generated to any rel/*
branch will have to be manually verified and merged, and they'll be listed
here.
Note that insertions for other teams will also be listed.
Insertions to any other VS branch (e.g., main
) will have the auto-merge flag set and should handle themselves, but
it's a good idea to check the previous link for any old or stalled insertions into VS main
.
Update the insertTargetBranch
value at the bottom of azure-pipelines.yml
in the appropriate release branch. E.g., when VS 17.3 snapped and switched to ask mode, this PR correctly updates the insertion target so that future builds from that F# branch will get auto-inserted to VS.
- Create a new
release/dev*
branch (e.g.,release/dev17.4
) and initially set its HEAD commit to that of the previous release (e.g.,release/dev17.3
in this case).git checkout -b release/dev17.4 git reset --hard upstream/release/dev17.3 git push --set-upstream upstream release/dev17.4
- Set the new branch to receive auto-merges from
main
, and also set the old release branch to flow into the new one. This PR is a good example of what to do when a newrelease/dev17.4
branch is created that should receive merges from bothmain
and the previous release branch,release/dev17.3
. - Set the packages from the new branch to flow into the correct package feeds via the
darc
tool. To do this:- Ensure the latest
darc
tool is installed by runningeng/common/darc-init.ps1
. - (only needed once) Run the command
darc authenticate
. A text file will be opened with instructions on how to populate access tokens. - Check the current package/channel subscriptions by running
darc get-default-channels --source-repo fsharp
. For this example, notice that the latest subscription shows the F# branchrelease/dev17.3
is getting added to theVS 17.3
channel. - Get the list of
darc
channels and determine the appropriate one to use for the new branch via the commanddarc get-channels
. For this example, notice that a channel namedVS 17.4
is listed. - Add the new F# branch to the appropriate
darc
channel. In this example, rundarc add-default-channel --channel "VS 17.4" --branch release/dev17.4 --repo https://github.com/dotnet/fsharp
- Ensure the subscription was added by repeating step 3 above.
- Note, the help in the
darc
tool is really good. E.g., you can simply rundarc
to see a list of all commands available, and if you rundarc <some-command>
with no arguments, you'll be given a list of arguments you can use. - Ensure that version numbers are bumped for a new branch.
- Change needed subscriptions for arcade and SDK:
darc get-subscriptions --target-repo fsharp
, and then usedarc update-subscription --id <subscription id>
for corresponding channels (e.g. target new VS channel to specific SDK channel, or set up arcade auto-merges to release/* or main branch, depending on the timeline of release/upgrade cycle).- If new subscription needs to be added, the following command should be used `darc add-subscription --source-repo https://github.com/dotnet/arcade --target-repo https://github.com/dotnet/fsharp --target-branch <target_branch> --channel "<target_channel>" --update-frequency everyDay --standard-automerge
- Update mibc and other dependencies if needed, refer to https://github.com/dotnet/arcade/blob/main/Documentation/Darc.md#updating-dependencies-in-your-local-repository for more information `
- Ensure the latest
Assign appropriate Area-*
label to bugs, feature improvements and feature requests issues alike. List of Area
labels with descriptions can be found here. These areas are laid out to follow the logical organization of the code.
To find all existing open issues without assigned Area
label, use this query
Since github issue filtering is currently not flexible enough, that query was generated by pasting output of this PowerShell command to the search box (might need to be rerun if new kinds of Area
labels are added):
Invoke-WebRequest -Uri "https://api.github.com/repos/dotnet/fsharp/labels?per_page=100" | ConvertFrom-Json | % { $_.name } | ? { $_.StartsWith("Area-") } | % { Write-Host -NoNewLine ('-label:"' + $_ + '" ') }