Skip to content

Commit 98a4bc3

Browse files
committed
Add information on how to update distro versions in the VMR
1 parent 6bd71d2 commit 98a4bc3

File tree

1 file changed

+67
-6
lines changed

1 file changed

+67
-6
lines changed

Documentation/ci-platform-coverage-guidelines.md

Lines changed: 67 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -44,10 +44,71 @@ matrix](https://github.com/dotnet/sdk/blob/main/eng/pipelines/templates/stages/v
4444
1. Alpine - Latest version (amd64)
4545
1. AlmaLinux - Oldest version (targets lowest glibc version) (amd64)
4646

47-
When updating the distro versions in the CI matrix as new versions are released
48-
and older versions reach EOL:
47+
## Updating Distro Versions in the VMR
4948

50-
1. Update `main` to the newer version one to two months prior to the GA/EOL date.
51-
This is done to flush out any issues and to avoid destabilizing the servicing
52-
branches.
53-
1. At the GA/EOL date, update the servicing branches.
49+
There are two scenarios when updating distro versions in the CI pipeline:
50+
51+
### Case 1: OS Used in N-1 Leg (Previous Version Support)
52+
53+
When updating a distro that is used in a n-1 (previous version) build leg:
54+
55+
1. Update pipeline build configuration variables
56+
57+
1. Create backup pipeline RID variable for old version:
58+
- Create a new distro RID variable with suffix `Old`
59+
(eg. if current variable is `centOSStreamX64Rid`, create `centOSStreamX64RidOld`)
60+
- Set the value to the RID of the old distro version being replaced
61+
62+
1. File tracking issue:
63+
- Create an issue in [dotnet/source-build](https://github.com/dotnet/source-build) repository
64+
- Title should indicate need to update artifacts RID after next rebootstrap or release
65+
- This ensures the old RID is properly cleaned up later
66+
67+
1. Update n-1 build legs:
68+
- Change the `artifactsRid` template parameter for n-1 build legs to use the `<name>Old` variable
69+
- Add a comment with a link to the issue created in step 3
70+
71+
1. Update prep-source-build.sh:
72+
- Add a comment above the [`defaultArtifactsRid`](https://github.com/dotnet/dotnet/blob/604a6612d130bc042dc973aba84889f529f9cb69/prep-source-build.sh#L40) variable to update the default value
73+
- Include a link to the issue created in step 3
74+
75+
1. Submit changes:
76+
- Open a pull request with all the above changes
77+
- Ensure all changes are reviewed and tested by doing a full run of the VMR
78+
- 8.0/9.0: [dotnet-source-build-pre10.0](https://dev.azure.com/dnceng/internal/_build?definitionId=1219)
79+
- 10.0+: [dotnet-unified-build](https://dev.azure.com/dnceng/internal/_build?definitionId=1330)
80+
81+
1. Update release pipeline infrastructure:
82+
- After the public PR is merged, update [the leg name(s)](https://dev.azure.com/dnceng/internal/_git/dotnet-release?path=/eng/pipeline/source-build-release/steps/re-bootstrap.yml&version=GBmain&line=68&lineEnd=86&lineStartColumn=1&lineEndColumn=1&lineStyle=plain&_a=contents) for the release artifacts to match the new configuration in the VMR
83+
- Create and merge this PR to complete the update process
84+
85+
1. Close tracking issue from step 3:
86+
- After the subsequent release or reboostrap (whichever comes first),
87+
open a PR with the changes linked to the tracking issue from step 3.
88+
- Merge the changes, and close the issue
89+
90+
### Case 2: Regular Artifact (Standard Update)
91+
92+
For distros not used in n-1 legs (simpler case):
93+
94+
1. Update build configuration variables
95+
1. Submit changes:
96+
- Open a pull request with all the above changes
97+
- Ensure all changes are reviewed and tested by doing a full run of the VMR
98+
- 8.0/9.0: [dotnet-source-build-pre10.0](https://dev.azure.com/dnceng/internal/_build?definitionId=1219)
99+
- 10.0+: [dotnet-unified-build](https://dev.azure.com/dnceng/internal/_build?definitionId=1330)
100+
101+
## Timing Guidelines for Distro Updates
102+
103+
When updating distro versions as new versions are released and older versions reach end-of-life (EOL):
104+
105+
1. **Pre-GA/EOL updates (1-2 months before):**
106+
- Update the `main` branch to use the newer distro version
107+
- This allows time to identify and resolve any compatibility issues
108+
- Helps avoid destabilizing servicing branches close to release dates
109+
- Follow guidelines described in [Permutations](#permutations)
110+
111+
2. **GA/EOL date updates:**
112+
- Update all active servicing branches (`release/x.0` branches)
113+
- Ensure consistency across all supported .NET versions
114+
- Follow guidelines described in [Permutations](#permutations)

0 commit comments

Comments
 (0)