Launch Windows Shared Runner beta
Problem to solve
In the 12.7 release we are launching the Windows runner shared fleet, in beta status.
Proposal
We will offer Windows Shared Runners on GitLab.com in beta. This issue will be used to capture any tasks required to support the beta launch.
- The development work that's being delivered in the Windows Shared Runners MVC will deliver the ability to autoscale Windows Runners on GitLab.com
- The Windows Shared Runners will be virtual machines (VM's) running on Google Cloud Platform (GCP).
- As is the case today with our Linux Shared Runners, each job that's executed on GitLab.com, and that makes use of a Shared Windows Runner will instantiate a new VM, therefore ensuring that each job is fully isolated.
- Even though the corresponding epic is a MVC, and we will have a viable solution when the MVC is released, we are opting to release this as a Beta version due to the need to validate usage patterns and scaling of this important feature.
Beta Specifications:
- Number of shared Windows runners in fleet: For Beta launch, the configured autoscale limit for the shared Windows Runners fleet will be set to ~15% of the actual max number of Linux Shared Runners in use on GitLab.com for the last 90 days.
- VM Windows OS version: Windows Server 2019 Core Datacenter Edition
windows-server-2019-dc-core-for-containers-v20190827
as a base image from GCP - VM specs: n1-standard-2 2 vCPU, 7.5GB RAM can be easily bumped.
- Default shell: Powershell
- Software on Windows VM: Single source of truth can be found in https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/master/cookbooks/preinstalled-software/README.md
Pricing:
- We will go out with Linux pricing for the beta.
- Pricing will likely be higher when the feature is generally available.
User Experience:
- Windows Shared Runners will be visible to users on GitLab.Com. Users will navigate to Settings/CI/CD in the left navigation menu.
- Windows Shared Runners will be displayed with a tag that identifies the Runner as Windows. Draft mockup attached:
- Users will have to specify the
shared-windows
tag in their project's .gitlab-ci.yml file in order to ensure that a job executes on a Windows Shared Runner hosted on Gitlab.com.
.gitlab-ci.yml
Example .shared_windows_runners:
tags:
- shared-windows
stages:
- build
- test
- package
before_script:
- date +"%H"
- echo ${HOUR}
- echo "started by ${GITLAB_USER_NAME}"
build:
extends:
- .shared_windows_runners
stage: build
script:
- echo "running scripts in the build job"
test:
extends:
- .shared_windows_runners
stage: test
script:
- echo "running scripts in the test job"
Beta Testing Feedback
- We will recruit users that have shown interest in this feature and request that they actively participate in testing the feature out during the beta period.
- A beta kickoff call will be held with the identified users. The purpose of that call is to..
- Gather a baseline set of data from the users in regards use cases, expectations for the capabilities available in the feature.
- Answer any questions that the users may have prior to the start of testing and to nail down a timeline of when they plan to pilot a test in their org to use the Windows Shared Runners.
- Schedule a follow up call to gather in person feedback. The purpose of the follow up call is to gather insights that we may not be able to infer from only the results of a survey.
- We will gather feedback from the recruited beta testers using the following mechanisms:
- Self-service feedback form for any users.
- User interviews will be conducted at the conclusion of each users planned tests.
- In addition, feedback will be collected from the recruited beta testers by a survey that will be sent to each tester at the conclusion of their initial tests.
- For issues encountered with the feature during testing, users will be instructed to raise an issue for a bug fix or feature enhancement request in the Runner project and tagging with
WindowsSharedRunner
.
Note: - As the beta release is not closed, we expect that other users may test out this feature. Their input and feedback is of course extremely valuable as well. All users can use this workflow to provide feedback or suggest a feature enhancement to the Beta version of the Windows Shared Runner fleet:
- Open and issue in the Runner project.
- Describe the feature enhancement and if possible include any links to examples.
- Add these labels to the issue: SharedRunners:Windows, group:runner
- Tag @DarrenEastman on the issue.
Beta success criteria
Product success criteria:
- Within three months of launch, the Windows Shared Runner fleet accounts for 10% of the jobs executed on GitLab.com
Launch Tasks
-
Create blog post for beta launch (coordinate with @williamchia) 1168 related MR for blog post 34599 Create video for beta launch (Decided that this was not critical path for beta launch. A speed run video will be created and posted to GitLab unfiltered. -
Create or update end user documentation (coordinate with @marcel.amirault) gitlab!23222 (merged) -
Final end-to-end test that the Windows runners are working as expected (@steveazz) -
Have a simple asp application build/test/package with artifacts and cache as a full end to end test for example https://gitlab.com/steveazz/playground/tree/windows-app
-
-
Finalize interim pricing for beta launch. 30834 -
Confirm that the Windows Shared Runners usage is tracked (coordinate with infrastructure) Instrumentation will be ready the week of Jan 20th. -
Confirm go-live plan with infrastructure team (@dawsmith) - gitlab-com/gl-infra/readiness!12 (closed) -
Confirm that support is aware and has the resources they need to support the beta (@lyle) -
Confirm and document the way to get feedback from customers during the period. (@DarrenEastman) 506 In addition a feedback form has been created and is included in the Blog post announcing the availability of the beta. -
Plan to validate technical success (usage patterns, scaling, etc.) of this important feature, to make sure that it's going to work for GA (coordinate @dawsmith and @tmaczukin) We will continue to refine this ahead of GA launch. I have copied this item to the new GA launch issue. -
Plan to validate product targets for beta. We need to understand what the success criteria are in advance, even if we have partial data and need to guess. (@DarrenEastman) We will measure usage using existing tooling on GitLab.com. Usage and adoption reports will be produced on a weekly basis.
Intended users
Software Developer - Specifically developers that are developing software for the Windows ecosystem.
Motivations:
- I need to be able to create a continuous integration pipeline for my Windows projects.
- I like GitLab CI/CD, but setting up GitLab Runner on Windows can be time consuming, and in some cases frustrating.
Customer Value Proposition: Shared Windows Runners gives users the tooling to build their Windows projects on GitLab.com without needing to setup and configure their own Windows build machines.
Further details
Permissions and Security
- The current assumption is that the launch of the Windows Shared Runners feature is consistent with existing permissions as documented for users, groups and projects.
- It is also assumed that the user behavior for exposing the Windows Shared Runner in the UI is consistent with the current method for how Linux Shared Runners are exposed to users.
- At this time, we aren't expecting to need any changes to the UI, specifically the CI/CD settings menu and resultant page to support the Windows Shared Runner feature.
Documentation
Documentation requirements | Notes |
---|---|
What concepts and procedures should the documentation guide and enable the user to understand or accomplish? | The content in this main paragraph needs to be updated to include details that are specific to the Windows Shared Runner. |
To this end, what new page(s) are needed, if any? What pages or subsections need updates? Consider user, admin, and API documentation changes and additions. | The content on this page mentions that if you use GitLab.com you can use the Shared Runners provided by GitLab inc. The link "read more on shared runners" links the reader over to another page that covers Configuring GitLab Runners, but it doesn't seem as if we have any additional content describing the Runners on GitLab.com |
For any guide or instruction set, should it help address a single use case, or be flexible to address a certain range of use cases? | Yes- any guide or instruction sets should be flexible enough the address a range of CI use cases for Windows developers |
Do we need to update a previously recommended workflow? Should we link the new feature from various relevant locations? Consider all ways documentation should be affected. | We may need to review the documentation here to make sure it's consistent with any new documentation on the Windows Shared Runner. |
Are there any key terms or task descriptions that should be included so that the documentation is found in relevant searches? | Windows, Shared Runners |
Include suggested titles of any pages or subsection headings, if applicable. | Pending feedback from tech writing team as to whether additional pages or subsections are required. |
List any documentation that should be cross-linked, if applicable. | To date - linked docs are identified in the rows above. |
Testing
Item to consider | Notes |
---|---|
What risks does this change pose? | Supporting Windows Runners on GitLab.com at scale is of course new, so there could be a potential increase in support requests or issues raised by the community once this feature is launched. |
Will it require cross-browser testing? | No - the current assumption is that there are no UI changes required in GitLab.com to expose the Windows Shared Runners to users. |