In order to reduce the number of disposable VMs we use, lets combine the composer-php55 and composer-hhvm jobs into one. Most are pretty short so doubling the runtime length probably won't be noticeable.
We just need to change the PHP_BIN variable before starting the second run.
| Project | Branch | Lines +/- | Subject | |
|---|---|---|---|---|
| integration/config | master | +28 -4 | Create combined PHP5.5 and HHVM composer-test job |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T142457 Combine composer-php55 and composer-hhvm jobs | |||
| Declined | None | T144959 Install PHP5.5 on jessie CI instances |
Once T144959: Install PHP5.5 on jessie CI instances is done, we can have one job that runs 5.5, 5.6, 7.0, and hhvm all on jessie.
Change 326020 had a related patch set uploaded (by Legoktm):
Create combined PHP5.5 and HHVM composer-test job
Change 326020 merged by jenkins-bot:
Create combined PHP5.5 and HHVM composer-test job
And reverted....set-phpflavor: hhvm failed. Do the trusty images have hhvm installed?
https://integration.wikimedia.org/ci/job/composer-php55-hhvm-trusty/1/console shows the failure of using php55 and not switching properly to hhvm.
OTOH https://integration.wikimedia.org/ci/job/mw-tools-codesniffer-mwcore-testrun/252/consoleFull worked properly, but that was on jessie.
I have moved the hhvm jobs from Trusty to Jessie a few weeks ago. Wikimedia production no more runs HHVM on Trusty and thus the Debian package is no more kept up-to-date.
So I guess lets get Zend 5.5 on Jessie using the sury packages ( T144959). Looks nicer to switch everything to Jessie on a long term basis.
(sorry for all the moving parts really :( )
Wait, I'm confused. The composer-hhvm-trusty jobs are still on trusty, so it has HHVM installed...right?
Yeah it is a bit messy :( Guess we can migrate the composer-hhvm job from trusty to jessie. The build counts:
composer-hhvm-trusty
composer-hhvm-jessie
A side note, it makes senses to run parallel-lint on different flavor of PHP. But for PHPCodeSniffer that is really just duplicate work :( No idea how we could handle that though.
Sadly, there have been differences in PHPCS depending upon hhvm vs php, (e.g., https://github.com/squizlabs/PHP_CodeSniffer/pull/669) so I think it's a good idea to run on both. And for most extensions, the amount of time it takes is trivial.
But I'm still confused. Do trusty nodepool instances have HHVM installed or not? They have to somehow since composer-hhvm-trusty worked.
Ahhh corner cases. So I guess it is a good thing to run everything on both flavors :]
But I'm still confused. Do trusty nodepool instances have HHVM installed or not? They have to somehow since composer-hhvm-trusty worked.
The Trusty instances do have HHVM installed, but it is no more updated AFAIK since Wikimedia prod is on Jessie. So I would rather follow the trend and eventually phase out Trusty entirely.
This would have been a good optimization in the nodepool era, but no longer makes sense in a docker world.