This page describes the Build Master role. This is a weekly rotating role.
- Make sure an Insider build is released daily
- Make sure the Continuous Build is green
Given build failures, make sure to pay attention to the #build Slack channel. It should notify who's likely responsible.
When there are hygiene or compilation errors, push a commit that fixes them and ping the responsible dev. If the fix isn't trivial, bring in the related developer to come up with a fix.
When there are test failures, comment out the test and create an issue for the test owner to fix. The same process applies even if the test is flaky. The rule is: a flaky test is as good as a failing test.
When there are code signing errors, retrigger builds. If the errors persist, file an issue to ESRP.
Else:
- Try to reason about the failure, get familiar with the build infrastructure and attempt to fix it.
- Reach out to the previous week's Build Master, they might know something.
- Reach out to João. Improve the Build Master process by documenting whatever he tells you.
The Continuous Build is a public, lightweight build which runs on every commit and PR and has access to no credentials. It exists to make sure our code base is clean, compilable and tests are happy on branches and pull requests.
The Product Build is a private, heavyweight build which runs daily to produce Insiders, so it has access to credentials. It exists to create all VS Code distributable assets and place them on our builds page. Note: it's important that it never runs on PRs of external forks of VS Code.
All our builds run in Azure DevOps and are scripted using YAML build definition files: