Split from main.
|Resolved||Reedy||T196206 Bump symfony libraries when we no longer need hhvm support|
|Resolved||Reedy||T234766 Consider what PHP 7.2 point release to use|
|Resolved||Jdforrester-WMF||T234767 Bump PHP support version in composer.json|
|Resolved||Jdforrester-WMF||T216166 Drop PHP 7.1 support from MediaWiki|
|Resolved||Jdforrester-WMF||T216165 Drop PHP 7.0 support from MediaWiki|
|Resolved||Jdforrester-WMF||T225457 Move all CI generic tasks from PHP70 to PHP72|
|Resolved||Jdforrester-WMF||T226420 Run phan secheck on PHP 7.2, not PHP 7.0|
|Resolved||Jdforrester-WMF||T227385 Upgrade php-ast in Seccheck CI containers|
|Resolved||Daimona||T227172 Upgrade taint-check to 2.0.1 in all repos|
|Resolved||sbassett||T227171 Release taint-check 2.0.0|
|Resolved||Daimona||T216974 Update phan-taint-check-plugin to a newer phan (1.3.2)|
|Resolved||Daimona||T218721 Have CI run seccheck tests|
|Resolved||Krinkle||T228342 Define criteria for setting explicit PHP support target for MediaWiki|
- Mentioned In
- T227385: Upgrade php-ast in Seccheck CI containers
T225325: LibraryUpgrader CI normalisation tasks, June/July 2019
T218719: Upgrade php-ast to 1.0.1 in CI composer-package containers
- Mentioned Here
- T218719: Upgrade php-ast to 1.0.1 in CI composer-package containers
T227172: Upgrade taint-check to 2.0.1 in all repos
Copying what I said in T227172: the current version (1.5.1) requires PHP70 jobs, while the new version (2.0.0) can run on PHP70+. I believe the easier way to proceed is to first upgrade seccheck in every repo, keeping the PHP70 job alone. When all repos are upgraded (or also gradually, whatever you prefer), we'll be able to switch to PHP72 jobs and get rid of the PHP72.
Note that something that can already be done is upgrade php-ast for both seccheck jobs, in the following way:
- PHP71+ jobs: These should only have php-ast 1.0.1, and T218719 should provide anything needed for the upgrade
- PHP70 job: This one is more complicated. It should behave the same as the phan job: if there's seccheck <=1.5.1 in composer.json, it should use php-ast 0.1.2. If there's seccheck 2.0.0 it should use php-ast 1.0.0.
Given the above, and the fact that upgrading ast may be a little harder than expected (as it happened in T218719), I'm un-stalling this task in case someone is interested in giving it a try.
@Jdforrester-WMF Well, T227172 is definitely a blocker and for that part yes, this one is stalled. However, as I said above, the seccheck containers have to be updated with the new php-ast, and that's something that can be done regardless of T227172. And actually, that task needs the PHP70 part described above, so they're blocking each other more or less.