Tue, Apr 23
I created a followup ticket that might resolve itself if we wait long enough and regularly update vue-cli. But in case that does not help, we need to implement a workaround for a webpack bug.
Thu, Apr 18
Pull request: https://github.com/wmde/FundraisingFrontend/pull/1470
Wed, Apr 17
I've tested the donation dumper script and found out that the recent changes for exporting address change data sets (https://github.com/wmde/fundraising-backend/pull/386, https://github.com/wmde/fundraising-backend/pull/387, https://github.com/wmde/fundraising-backend/pull/388 ) have not been deployed. To avoid a situation where localizing errors becomes hard, I've manually edited the export script to use the "old style" parameters (--gruen field set instead of --tokenless-gruen --export-types=donation,membership,subscription). When the 3rd party gives their ok, deploy the FOC code base and do another round of deployment for the backend server.
I've deployed the updated script to the backend server. I've commented out the deletion of the ZIP file, just in case something goes wrong.
As a small followup, you could also do T213278: Revert Pull Request that restored PHP 7.1 compatibility
Mon, Apr 15
Fri, Apr 12
I've put together a proof-of-concept that sets the variable during deployment: https://github.com/wmde/FundraisingFrontend/pull/1466
I have changed the connection and LDAP search information in https://github.com/wmde/fundraising-infrastructure/pull/262 and deployed the changes. Login should work again, now with the login data (short 4-char username) you use for other LDAP-backed WMDE services. Please try it out.
Thu, Apr 11
I've removed the story points (they were distributed to the subtasks) and removed the task from the sprint (because it no longer has points and is a collection task).
Wed, Apr 10
Here is my perspective as one of the developers of the AdvancedSearch extension, which heavily uses OOUI: What is an "integration test"?
Mon, Apr 8
Wed, Apr 3
Temporarily reverted a patch with https://github.com/wmde/fundraising-infrastructure/pull/259 and deployed it to test and production, now the cache is cleared again.
Tue, Apr 2
I had another look and found the error: Ubuntu 14.04 does not use Systemd yet (it uses upstart) and in preparation for the Update to 18.04 I removed the upstart configuration (PR https://github.com/wmde/fundraising-infrastructure/pull/254), misreading the info at https://wiki.ubuntuusers.de/systemd/ (German site).
Mon, Apr 1
Possible split of this ticket:
Fri, Mar 29
It seems like the umask settings fo php-fpm are not overwritten correctly, leading to the cache files being not group-writable (for group www, where the deploy user is a member). The umask settings should be overwritten by the file /etc/systemd/system/php7.3-fpm.service.d/override.conf (generated through our infrastructure playbooks).