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.
|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|
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.
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.
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.
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.
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