Popups has a test to ensure that the build product is in sync with the source input files. Given a clean Git status, it is an error, often critical, for a build to generate different output than what was committed. This is because the build product is versioned alongside the source and committing files also publishes them in a sense. This task encompasses the work to add a precommit test similar to Popups. npm -s run build && git diff -q /resources/dist.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Jdlrobson | T195473 [GOAL] Invest in the MobileFrontend & MinervaNeue frontend architecture | |||
| Resolved | Jdlrobson | T195475 [EPIC] Automate asset bundling in MobileFrontend | |||
| Resolved | Jdlrobson | T202747 Add build product synchronization test | |||
| Resolved | • Niedzielski | T202748 [Bug] Popup build synchronization tests are not failing when they ought to | |||
| Resolved | • Niedzielski | T203522 Popups php unit tests mysteriously failing and blocking merges |
Event Timeline
Comment Actions
Im curious if we need one.
To be honest I'd much rather explore a "as and when needed" approach to generating the dist rather than on every commit given the issues we have in Popups with rebasing.
The build is only actually needed when Selenium tests fail without it which usually relates to server side changes.
Comment Actions
I'm down with chatting but please consider that if we're versioning build products, this doesn't affect the rebase problem. We just recently had a commit get a +1 that had a TypeError in Popups and I frequently see rebase failures creep in.
Comment Actions
If we only build assets on a friday for example (e.g. as part of chores) we wouldn't ever get rebase problems. I've not looked into the Popups case just yet but a TypeError should really be picked up by integration or unit test.
Comment Actions
I've not looked into the Popups case just yet but a TypeError should really be picked up by integration or unit test.
The TypeError is an example and fully accounting for it would require 100% code coverage. Additionally, erroneous code is not limited to those that throw Errors.
Comment Actions
We talked about this in the CR session today and the idea was banded about that we attempt a new approach inside MobileFrontend - using the build process as a way of being in control of what get's deployed. Two ideas proposed were low effort - building on a certain day e.g. Monday morning or using a dev branch and building to master when needed. A third idea was to use a separate deploy repo like services do, but that one would need more discussion.
Hopefully we can delay this conversation until you get back @Niedzielski
Comment Actions
@Jdlrobson, can we close this? I think we covered it in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/468488/.