This task tracks working with the Release Engineering team to enable PipelineBot in Vector. The workflows needed are as follows.
== Workflows
=== Code review workflow
1. A patch is submitted.
2. NPM and system dependencies are installed or already downloaded within the image. For example, `npm install`.
3. An NPM build script is executed. For example, `npm run build`.
4. 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
- [[ https://wikitech.wikimedia.org/wiki/PipelineLib/Guides/How_to_define_a_node_test_pipeline | How to define a Node test pipeline ]]
- [[ https://gerrit.wikimedia.org/r/plugins/gitiles/wikibase/vuejs-components/+/refs/heads/master/.pipeline | vuejs-components ]]?
- [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/services/mobileapps/+/master/.pipeline/ | mobileapps ]]?
- https://wikitech.wikimedia.org/wiki/PipelineLib
- https://gerrit.wikimedia.org/r/c/mediawiki/services/push-notifications/+/594352/
- ...?
=== Deployment workflow
1. A Docker image is booted and a patch is mounted.
2. NPM and system dependencies are installed or already downloaded within the image. For example, `npm install`.
3. An NPM build script is executed. For example, `npm run build`.
4. 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:
1. Backport the source code fix as a Gerrit / GitLab patch on an old branch.
2. 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.
== Other references
- [[ https://github.com/wikimedia/fresh | Timo's fresh ]]
- [[ https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/MW-in-Containers_thoughts | It's my MediaWiki in a box ]]
- [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Popups/+/master/.nvmrc | NVM config example from Popups ]]
- T254837