This task tracks working with the Release Engineering team to enable PipelineBot in Vector. The workflows needed are as follows.
Workflows
Code review workflow
- A patch is submitted.
- NPM and system dependencies are installed or already downloaded within the image. For example, npm ci.
- An NPM build script is executed. For example, npm run build.
- Test scripts are executed on / with the build products.
Solution
We currently run npm test. Add a pipeline config that will execute npm test in a container instead.
References
- How to define a Node test pipeline
- vuejs-components?
- mobileapps?
- https://wikitech.wikimedia.org/wiki/PipelineLib
- https://gerrit.wikimedia.org/r/c/mediawiki/services/push-notifications/+/594352/
- ...?
Deployment workflow
- A Docker image is booted and a patch is mounted.
- NPM and system dependencies are installed or already downloaded within the image. For example, npm install.
- An NPM build script is executed. For example, npm run build.
- The artifacts are copied out of the Docker image to a remote server or repo. For example, rsync build-box:/mnt/vector/patch101/dist 192.168.somewhere/vector/patch101/
Solution
????
Backport workflow
Largely the same as deployment, perhaps identically:
- Backport the source code fix as a Gerrit / GitLab patch on an old branch.
- The patch goes through the normal pipeline as per usual.
Solution
????
Acceptance criteria
- Vector master is built automatically and rides the train like all other code.
- Build products are available in the tarball _or_ a prioritized task to add them is made.
- Build failures block code merges in Gerrit and deployments.
- Any changes to the build script only requires changes to Vector itself and not other repos. It's important that frontend developers don't have to become release engineers to make changes.
- The process for adding or removing dependencies is minimized. If it's more than npm install and a security review, it should be documented. It's important that frontend developers don't have to become politicians or process experts to make changes.
- Backport workflows are as similar to standard deployments as possible. Ideally, just a cherry-pick and going through the same process.
- A Docker configuration that contains all dependencies is made.
- A PipelineLib configuration is made.
- The above changes have little or no impact on frontend developer workflows.
- Documentation for anything a non-RelEng developer would want to know about the above is included in the repo.