ci: Update workflows and conan to use VS2026 and grpc 1.81.0#7550
ci: Update workflows and conan to use VS2026 and grpc 1.81.0#7550a1q123456 wants to merge 4 commits into
Conversation
a1q123456
added
the
DraftRunCI
a1q123456
changed the title
a1q123456
force-pushed
the
a1q123456/use-vs2026
branch
from
138db79 to
933dfc0
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #7550 +/- ##
=========================================
- Coverage 82.0% 82.0% -0.0%
=========================================
Files 1009 1009
Lines 76782 76782
Branches 8940 8937 -3
=========================================
- Hits 62978 62976 -2
- Misses 13795 13797 +2
Partials 9 9 see 6 files with indirect coverage changes 🚀 New features to boost your workflow:
|
![xrplf-ai-reviewer[bot]](https://avatars.githubusercontent.com/u/67929741?s=60&v=4){kind=small}
|
Making it a draft until I finish updating the devbox labels |
| { | ||
| "platform": "windows/amd64", | ||
| "runner": ["self-hosted", "Windows", "devbox"], | ||
| "runner": ["self-hosted", "Windows", "dev-box-windows-2026"], |
There was a problem hiding this comment.
@a1q123456 please see my comments first on the separate Terraform PR. I'd like for these labels to be changed for consistency.
There was a problem hiding this comment.
Yes, I'm going to update the labels and then make this pr ready.
There was a problem hiding this comment.
Also I'll pin the chocolatey package versions.
There was a problem hiding this comment.
Just realised that we can't make the 2 sets of runners share the same label.
There was a problem hiding this comment.
Since we won't merge this until next Tuesday to give others time to prepare, I still recommend adjusting the labels the day over the switchover such that:
- Windows Server 2022 / Visual Studio 2022:
"self-hosted", "Windows", "devbox"- This will not change the existing runners, so they won't be updated and we can roll back easily. If the rollout goes well, then we can remove these runners fully.
- Windows Server 2026 / Visual Studio 2026:
"self-hosted", "Windows", "devbox", "vs2026"- There will be some ~30mins when we can't build, while the new machines are redeployed and reregistered, and then this PR is merged afterwards.
- The benefit of doing this is that the existing logic to remove offline GitHub runners can then stay the same (the new Powershell logic is overly complex), since you check for runners with the
devboxlabel, and that applies to all machines, now and in the future.
There was a problem hiding this comment.
I think in the second bullet point, it should have been 2026.
Given that, this is a bad suggestion because a label set for 2026 is a superset of the one for 2022.
It means that if implemented this way, old branches will be able to choose both the 2022 and 2026 runners.
Note: GitHub logic is "if the runner has all labels requested, then it's acceptable". It doesn't require to be no extra labels, or sth like that.
We'll eventually sunset old runners, but even after we merge the change to develop, we should give some time (again, a week, probably) for people to update branches, so it won't be immediate, and we don't want the same code to get a new meaning in that time.
The current implementation avoids this problem.
We can name it more nicely if needed, but just adding label(s) to the existing set of labels won't definitely work.
There was a problem hiding this comment.
Fixed my comment.
Ok, let's just fix the labels after a few weeks, once the vs2022 runners have been turned down.
There was a problem hiding this comment.
Btw, if we expect there to be 3.2.1, we can't sunset our runners till we release a new major release (or we'll have to disable Windows for 2.7.1).
mathbunnyru
changed the title
3 participants
High Level Overview of Change
This PR updates the pipeline to use the visual studio 2026 runners and extends the timeout to allow windows runners to finish building dependencies
Context of Change
API Impact
libxrplchange (any change that may affectlibxrplor dependents oflibxrpl)