Would it be worth doing an upgrade locally and then start making tasks to fix the things that are broken (assuming things break)?

Yeah for sure. I think the upgrade could be broken down into these piecemeal steps:

• Upgrade to PHP 7.2. This is the only thing that has to be done before everything else. Sam and I are already on 7.2 locally and everything works. So I think we're good there, just need to move the app to the 7.2 container on Toolforge (simple).
• Core Symfony upgrade. This seems to mostly involve moving files around to match the new directory structure. There are a lot of deprecations as well, but those hopefully won't be too hard to fix.
• Moving from Assetic (unmaintained PHP-based asset management) to Webpack Encore. It is possible to upgrade to Symfony 4 and stay on Assetic, but Assetic is dead and it must go at some point. We don't have very complicated JavaScript as it is, so this upgrade is low-priority I think.
• Upgrading to Symfony Flex. Also not required in Symfony 4, but it's a good idea and this is what will allow for an easier setup, and a significantly smaller footprint (as we only use the Symfony packages that we need).

I'm probably missing more things. I spent the other night attempting to do all of the above for XTools. I got pretty far but did not finish. To me it seemed like the biggest pain was the upgrade to Flex, though I can't really say for sure because I tried to do everything all at once.

Per usual when I do Symfony development I sometimes look for answers to problems on StackOverflow. Every time I see comments like "this is no longer works and/or is deprecated in Symfony 4". That's what worries me :/

My guess is overall it's a day or two of work. During this time all feature development should be on hold. My thoughts are to get it over with so we can stop worrying about it.

Thanks for the detailed list. It might make sense to elevate some of that to the description itself for greater visibility.

@MusikAnimal You can create separate tickets, if you like.

I only figured these things out when I worked in upgrading XTools. The list is likely incomplete but I'll add what I have, and make them checkboxes in the task description. A true "upgrade" would entail us doing all of them. When I have the free time I'll finish up XTools and will be able to give a clearer picture of what to expect.

I actually think we could even continue with feature development in parallel, if we want. Once the upgrade is complete, you'll need to start a new PR (from your existing unmerged PR) copying over your work to wherever the files now live, and resolve conflicts that way. Thus far with XTools I haven't had to change any of business logic, just namespaceing, use statements and the config files that you otherwise never touch.

The staging site is now running on PHP 7.2.

In T201437#4517570, @Samwilson wrote:

The staging site is now running on PHP 7.2.

Excellent!

@Mooeypoo to consider splitting the second 2 checkboxes, the estimate is just for the first 2

So Assetic is not available for Symfony 4 (I thought it was, but was just discouraged), so we have to switch to Webpack first.

That's more work but not necessarily wasted effort. It's an improvement for the stack.

A great example of why estimates are estimates. You never know what you might find. :)

I've updated production to PHP 7.2. A small issue with the cache not clearing properly (did it manually and all is okay now).

Production is back on 5.6.

The Redis problem has been solved (see T188318), and the staging site is functioning correctly, e.g.: https://tools.wmflabs.org/grantmetrics-test/app.php/programs/Joe%27s_program/June_2018/revisions

Another upgrade increment (to change the docroot): https://github.com/wikimedia/grantmetrics/pull/107

PR ready for review: https://github.com/wikimedia/grantmetrics/pull/105

This is at last the actual Symfony upgrade.

Reviewed and merged! I did a run-through on staging. I had to make one small follow-up commit but otherwise everything looks great. Thanks for making this happen, Sam!

Did we want to do any additional QA? Tests are comprehensive and they're passing, so you shouldn't need to QA the stats and what not.

@MusikAnimal It might be nice to get everyone on the team to just click through things a bit and see what's what.

One final PR for this: https://github.com/wikimedia/grantmetrics/pull/113

Is it okay to deploy this to prod?

There are a few reoccurring errors in the logs, e.g.:

[2018-09-10 23:38:50] php.WARNING: Warning: A non-numeric value encountered {"exception":"[object] (ErrorException(code: 0): Warning: A non-numeric value encountered at /data/project/grantmetrics-test/vendor/krinkle/intuition/src/Intuition.php:1347)"} []

[2018-09-10 23:38:51] request.ERROR: Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\HttpException: "" at /data/project/grantmetrics-test/src/AppBundle/Controller/EntityController.php line 181 {"exception":"[object] (Symfony\\Component\\HttpKernel\\Exception\\HttpException(code: 0): at /data/project/grantmetrics-test/src/AppBundle/Controller/EntityController.php:181)"} []

But I don't think these are related to the upgrade. I think it's good to deploy.

The former logged warning is Intuition's fault; I've made this to fix it: https://github.com/Krinkle/intuition/pull/91

The latter is not what it says it is, so it's hard to track down. :-)

It seems to work okay from my tests on staging. I think it should be okay to deploy.