Implement subset source-only build branches

[mmitche]

Follow on work from discussions here: #3738

Based on this discussion, the following will happen:

• We will change the VMR sync such that it will sync into a branch without cloaking. Let's call this the VMR-All branch
• We will provide a distro-maintainer-centric branch which will comply with your requirements like the existing branch does.
• This branch will be a subset of the VMR-All branch, related in git history. Let's call this a VMR-SourceOnly branch. It will have the cloaked set of files removed.
• These cloaked files may also include repos that are not interesting for distro maintainers, e.g. winforms
• PRs that update a VMR-All branch will also test updates to the corresponding VMR-SourceOnly branch.
• Upon checkin, the VMR-SourceOnly branch will be immediately updated (no lag) via a merge process.
• On release day, we will create two tags and two releases. One tag will point to the VMR-All content for the release, and the other to the source only compatible content.

Design Details

Branch Naming

• Primary branch names (e.g. main and release/8.0.1xx) remain unchanged.
• Source-only branches are named with a /source-only suffix: (e.g. main/source-only and release/8.0.1xx/source-only)

Release Tag Naming

• Primary tag names are unchanged from previous names. (e.g. v8.0.1)
• Source-only tags are named with a -source-only suffix (e.g. v8.0.0-source-only).

Release content

• Release content for the primary tag is updated to indicate the tag that should be used for source-only builds
• Source-build release content is updated to indicate that the tag should be used for source-only builds.

Work Items

• Remove cloaking from primary VMR sync #3990
• Sync source-only branch on check-in #3997
• Implement mechanism to merge to source-only branch from primary branch and apply exclusions #3991
• Update VMR build scripting to suggest correct branches to use when building #3992
• Update release automation to create source-only build tags #3993
• Retarget VMR CI source-only build pipelines to source-only branches #3994
• Implement test source-only branch test sync and build on installer PRs #3995
• Implement test source-only branch test sync and build on VMR-full PRs #3996

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[mmitche]

@premun

[jkotas]

Source-only branches are named with a /source-only suffix:

The key characteristic of these branches is that they are tailored to the needs of Unix distros. Should the suffix naming reflect that? E.g. unix-distro suffix?

[mmitche]

Source-only branches are named with a /source-only suffix:

The key characteristic of these branches is that they are tailored to the needs of Unix distros. Should the suffix naming reflect that? E.g. unix-distro suffix?

Maybe distro-maintainer? I'm fine with any naming here as long as it's pretty clear to users.

[premun]

Maybe it's better to say what is in the branch (like /source-only) rather than trying to describe the purpose of how it should be used as that can grow/change over time?
E.g. we might start using these for some non-distro-related purpose?

[mmitche]

Possibly. @MichaelSimons and I chatted more about this yesterday and he doesn't love the delta-branch approach much. Let's chat more tomorrow. It's possible that we could keep a set of cloaking and use the same branch, but this will require time to evaluate.

[mmitche]

It's likely this work will not be required as we may use a pre-build script for distro maintainers. If not, we should close all items and open a new Epic + items for that.

[mmitche]

Going with a different solution in #4088

[tkapin]

Going with a different solution in #4088

Since we are going with a different solution, I'm removing the Epic label to get this off of the roadmap.