So we've got php7 containers, but they aren't really that useful because php7 isn't "done" yet. So we need to keep the php7 containers updated with a most recent build of php7. Otherwise the env will show failures that may or may not be bugs in php7 itself that may or may not have been addressed.

Additionally the assumption is that we're not going to automate builds of php7, so it would be useful for the test reviewers to know which version of php was built so they can know if some fails are important or not.

Comments

Mixologic’s picture

Until we actually upgrade the bots, at the very least, this is what they are running:

PHP 7.0.0-dev (cli) (built: Aug  3 2015 18:30:58) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies
Mixologic’s picture

Berdir’s picture

This is the problem atm with PHP 7 :)

See #2547715: Cannot access protected property $this->storage on Install inside SqlContentEntityStorageSchema::

The bug was fixed, but until we update PHP7, then DrupalCI results for PHP7 will be useless.

webchick’s picture

Priority: Normal » Critical
Issue tags: +infrastructure blocker for Drupal 8.0.0

From our discussion today, I understood this to be a blocker to Drupal 8. Raising to critical and adding the tag.

Mixologic’s picture

Status: Active » Needs review

We've added php version display to the console log output, and are doing a docker pull if the environment is php7.

https://dispatcher.drupalci.org/job/php7_mysql5.5/40/consoleFull

Right now the build is a manual one button trigger, but can be executed on demand - we're delayed on docker hub to fix an issue with their remote build trigger api.

Until such time we can rebuild php7 whenever the devs need it.

isntall’s picture

Status: Needs review » Fixed

The blocker for automatic builds has been fixed

We have setup a cron to build daily web-7 containers.
The dispatcher job for php 7 will pull the latest web-7 container every run.
And we are displaying the version info with
php -v

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Mixologic’s picture

Status: Closed (fixed) » Active

We need to update to use the proper branch. Not sure which one we should use - Right now we're using "Master" which moved us over to 7.1, which isnt what we want.

So we have the option of either chasing PHP-7.0, which is the 7.0 dev branch, or we follow PHP-7.0.0, which is the release branch for php7, so we'' only go from one RC to the next.

Mixologic’s picture

Since we are using php-build to create builds of php on the fly, we're going to use the definition file they already have defined: https://github.com/php-build/php-build/blob/master/share/php-build/defin... which equates to the 7.0 branch. so we'll still be bleeding edge, just not 7.1 anymore.

  • isntall committed 8cb98eb on 2539496-PHP-7-testing-needs-recent-builds-and-needs-to-display-the-build-number
    Issue #2539496 by Mixologic, isntall: PHP 7 testing needs recent builds...
isntall’s picture

Status: Active » Needs review
Mixologic’s picture

Status: Needs review » Reviewed & tested by the community

LGTM++ hotfix and rebuild at will.

Mixologic’s picture

Status: Reviewed & tested by the community » Fixed

Well, we're back onto the PHP-7.0 branch. But we still have 100 segfault fails.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.