Page MenuHomePhabricator

REL1_35 docker image incompatible with requirements
Closed, ResolvedPublic

Description

Trying to use Docker on the 1.35 branch fails at composer update due to:

+ docker-compose exec mediawiki composer update

ComposerHookHandler::onPreUpdate

Loading composer repositories with package information
Warning from https://repo.packagist.org: You are using an outdated version of Composer. Composer 2 is now available and you should upgrade. See https://getcomposer.org/2
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

Problem 1
  - This package requires php >=7.3.19 but your PHP version (7.2.31) does not satisfy that requirement.
Problem 2
  - Installation request for doctrine/dbal 3.0.0 -> satisfiable by doctrine/dbal[3.0.0].
  - doctrine/dbal 3.0.0 requires php ^7.3 || ^8.0 -> your PHP version (7.2.31) does not satisfy that requirement.

and the image docker-registry.wikimedia.org/dev/stretch-php72-fpm-apache2-xdebug:0.4.0 is (apparently) only providing PHP 7.2.

master is working OK, I guess because it was doctrine/dbal": "2.10.4||3.0.0.

Event Timeline

Still a problem on origin/REL1_36. https://www.mediawiki.org/wiki/Compatibility#PHP says to use 7.3.19+ or 7.4.9+ (since 1.35). For now, use docker-registry.wikimedia.org/dev/stretch-php74-fpm:3.0.0 and docker-registry.wikimedia.org/dev/stretch-php74-jobrunner:2.0.0 and then switch to buster-php74 after T273100: dev-images: upgrade images for MediaWiki-Docker from wikimedia-stretch to wikimedia-buster.

Does it make sense in general to use php74 for the dev images?

Apparently those images also have php-ast in them (cf. T286677)

Change 767585 had a related patch set uploaded (by MarkAHershberger; author: MarkAHershberger):

[mediawiki/core@master] Bump PHP version for docker compose to php 7.4

https://gerrit.wikimedia.org/r/767585

Change 821787 had a related patch set uploaded (by Krinkle; author: Jforrester):

[mediawiki/core@master] MediaWiki-Docker: Switch PHP images to PHP7.4

https://gerrit.wikimedia.org/r/821787

Change 821787 merged by jenkins-bot:

[mediawiki/core@master] MediaWiki-Docker: Switch PHP images to PHP7.4

https://gerrit.wikimedia.org/r/821787

Change 822164 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/core@REL1_38] MediaWiki-Docker: Switch PHP images to PHP7.4

https://gerrit.wikimedia.org/r/822164

Change 822165 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/core@REL1_37] MediaWiki-Docker: Switch PHP images to PHP7.4

https://gerrit.wikimedia.org/r/822165

Change 822386 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/core@REL1_35] MediaWiki-Docker: Switch PHP images to PHP7.4

https://gerrit.wikimedia.org/r/822386

Change 822386 abandoned by Jforrester:

[mediawiki/core@REL1_35] MediaWiki-Docker: Switch PHP images to PHP7.4

Reason:

We don't have a PHP7.4 + Apache + xdebug image to offer.

https://gerrit.wikimedia.org/r/822386

Change 822165 merged by jenkins-bot:

[mediawiki/core@REL1_37] MediaWiki-Docker: Switch PHP images to PHP7.4

https://gerrit.wikimedia.org/r/822165

Change 822164 merged by Jforrester:

[mediawiki/core@REL1_38] MediaWiki-Docker: Switch PHP images to PHP7.4

https://gerrit.wikimedia.org/r/822164

Change 767585 abandoned by Krinkle:

[mediawiki/core@master] Bump PHP version for docker compose to php 7.4

Reason:

Superseded by T295958 / https://gerrit.wikimedia.org/r/821787

https://gerrit.wikimedia.org/r/767585

Krinkle assigned this task to Jdforrester-WMF.
Samwilson subscribed.

Sorry to reopen this, but it looks like the issue isn't solved for REL1_35 (which is specifically the topic of this task). The patch for that branch was abandoned with the comment "We don't have a PHP7.4 + Apache + xdebug image to offer."

It looks like the issue is fixed for other more recent releases, but 1.35 is still supported and so it's still useful to be able to test extensions with it. Is there a workaround for this?

@Jdforrester-WMF I don't understand your comment on that patch, do you mind rephrasing? Wouldn't specifying these images work for REL1_35?

services:
  mediawiki:
    image: docker-registry.wikimedia.org/dev/buster-php74-fpm:1.0.0-s3
  mediawiki-jobrunner:
    image: docker-registry.wikimedia.org/dev/buster-php74-jobrunner:1.0.0-s2

@Samwilson if you are testing with REL1_35, you could try putting the contents of the YAML block above into a docker-compose.override.yml file to see if that works for you.

@Jdforrester-WMF I don't understand your comment on that patch, do you mind rephrasing? Wouldn't specifying these images work for REL1_35?

services:
  mediawiki:
    image: docker-registry.wikimedia.org/dev/buster-php74-fpm:1.0.0-s3
  mediawiki-jobrunner:
    image: docker-registry.wikimedia.org/dev/buster-php74-jobrunner:1.0.0-s2

It'll drop xdebug support, which IIRC people in IRC said was too much of a loss, but no-one stood up to build the images with xdebug in. I suppose we could do this, if someone really is still trying to do development on 1.35.

@Jdforrester-WMF I don't understand your comment on that patch, do you mind rephrasing? Wouldn't specifying these images work for REL1_35?

services:
  mediawiki:
    image: docker-registry.wikimedia.org/dev/buster-php74-fpm:1.0.0-s3
  mediawiki-jobrunner:
    image: docker-registry.wikimedia.org/dev/buster-php74-jobrunner:1.0.0-s2

It'll drop xdebug support, which IIRC people in IRC said was too much of a loss, but no-one stood up to build the images with xdebug in. I suppose we could do this, if someone really is still trying to do development on 1.35.

Does it drop xdebug support? Sorry if I am missing something obvious.

docker run --rm -it --entrypoint=bash docker-registry.wikimedia.org/dev/buster-php74-fpm:1.0.0-s3
root@78722e091cd9:/var/www/html/w# php --version
PHP 7.4.30 (cli) (built: Sep 18 2022 12:49:13) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.30, Copyright (c), by Zend Technologies
    with Xdebug v3.0.4, Copyright (c) 2002-2021, by Derick Rethan

you could try putting the contents of the YAML block above into a docker-compose.override.yml file to see if that works for you.

Thanks! I had to change some paths too:

services:

    mediawiki:
        image: docker-registry.wikimedia.org/dev/buster-php74-fpm:1.0.0-s3
        volumes:
            - ./:/var/www/html/w:cached
        environment:
            COMPOSER_CACHE_DIR: '/var/www/html/w/cache/composer'
            MW_SCRIPT_PATH: '/w'
            MW_DBPATH: '/var/www/html/w/cache/sqlite'
            MW_LOG_DIR: /var/www/html/w/cache

    mediawiki-jobrunner:
        image: docker-registry.wikimedia.org/dev/buster-php74-jobrunner:1.0.0-s1
        volumes:
            - ./:/var/www/html/w:cached
        environment:
            MW_LOG_DIR: /var/www/html/w/cache
            MW_INSTALL_PATH: /var/www/html/w

But actually it seems this won't work, because buster-php74-fpm doesn't have a web server.

I've tried adding the 3rd image:

mediawiki-web:
    image: docker-registry.wikimedia.org/dev/buster-apache2:1.0.0
    user: "${MW_DOCKER_UID}:${MW_DOCKER_GID}"
    ports:
        - "8081:8080"
    volumes:
        - ./:/var/www/html/w:cached
    env_file:
        - '.env'
    environment:
        MW_LOG_DIR: /var/www/html/w/cache

(With a different port so it doesn't conflict with the first image.) But that seems to break database access for some reason ("Cannot access the database: Unknown error (localhost)"). I'll keep trying.

you could try putting the contents of the YAML block above into a docker-compose.override.yml file to see if that works for you.

Thanks! I had to change some paths too:

services:

    mediawiki:
        image: docker-registry.wikimedia.org/dev/buster-php74-fpm:1.0.0-s3
        volumes:
            - ./:/var/www/html/w:cached
        environment:
            COMPOSER_CACHE_DIR: '/var/www/html/w/cache/composer'
            MW_SCRIPT_PATH: '/w'
            MW_DBPATH: '/var/www/html/w/cache/sqlite'
            MW_LOG_DIR: /var/www/html/w/cache

    mediawiki-jobrunner:
        image: docker-registry.wikimedia.org/dev/buster-php74-jobrunner:1.0.0-s1
        volumes:
            - ./:/var/www/html/w:cached
        environment:
            MW_LOG_DIR: /var/www/html/w/cache
            MW_INSTALL_PATH: /var/www/html/w

But actually it seems this won't work, because buster-php74-fpm doesn't have a web server.

I've tried adding the 3rd image:

mediawiki-web:
    image: docker-registry.wikimedia.org/dev/buster-apache2:1.0.0
    user: "${MW_DOCKER_UID}:${MW_DOCKER_GID}"
    ports:
        - "8081:8080"
    volumes:
        - ./:/var/www/html/w:cached
    env_file:
        - '.env'
    environment:
        MW_LOG_DIR: /var/www/html/w/cache

(With a different port so it doesn't conflict with the first image.) But that seems to break database access for some reason ("Cannot access the database: Unknown error (localhost)"). I'll keep trying.

Sorry, I forgot about mediawiki-web. I think you could copy the entire contents of docker-compose.yml from REL1_39 and that would work for REL1_35.

Change 822386 restored by Kosta Harlan:

[mediawiki/core@REL1_35] MediaWiki-Docker: Switch PHP images to PHP7.4

https://gerrit.wikimedia.org/r/822386

Yes, the above patch works great. Thanks.

The only error I'm getting is:

mediawiki-mediawiki-jobrunner-1 | Notice: Trying to access array offset on value of type bool in /var/www/html/w/maintenance/includes/Maintenance.php on line 651

which looks like it is T283191.

Change 822386 merged by jenkins-bot:

[mediawiki/core@REL1_35] MediaWiki-Docker: Switch PHP images to PHP7.4

https://gerrit.wikimedia.org/r/822386

All good now I think.

@Jdforrester-WMF I don't understand your comment on that patch, do you mind rephrasing? Wouldn't specifying these images work for REL1_35?

services:
  mediawiki:
    image: docker-registry.wikimedia.org/dev/buster-php74-fpm:1.0.0-s3
  mediawiki-jobrunner:
    image: docker-registry.wikimedia.org/dev/buster-php74-jobrunner:1.0.0-s2

It'll drop xdebug support, which IIRC people in IRC said was too much of a loss, but no-one stood up to build the images with xdebug in. I suppose we could do this, if someone really is still trying to do development on 1.35.

Does it drop xdebug support? Sorry if I am missing something obvious.

Sorry, I had a thought-o and wrote 'xdebug' rather than 'apache' (probably because it's the last word in the name of the old image, rather than the penultimate?).

Glad everyone else worked out what I meant anyway. :-)