magento / magento-cloud-docker

All Submissions you make to Magento Inc. (“Magento") through GitHub are subject to the following terms and conditions: (1) You grant Magento a perpetual, worldwide, non-exclusive, no charge, royalty free, irrevocable license under your applicable copyrights and patents to reproduce, prepare derivative works of, display, publically perform, sublicense and distribute any feedback, ideas, code, or other information (“Submission") you submit through GitHub. (2) Your Submission is an original work of authorship and you are the owner or are legally entitled to grant the license stated above. (3) You agree to the Contributor License Agreement found here: https://github.com/magento/magento2/blob/master/CONTRIBUTOR_LICENSE_AGREEMENT.html

Open Software License 3.0

256 stars 192 forks source link

Set php-fpm and php-cli containers to launch as www user #304

Closed lobre closed 3 years ago

lobre commented 3 years ago

Hello,

This PR is to answer https://github.com/magento/magento-cloud-docker/issues/303.

There are two things that it tackles:

launches php cli containers as www and
changes php fpm pool configuration to use www as well.

That way, no files are created as root. I have tested an installation of Magento using the generated docker-compose.yml with Magento Commerce Cloud (and just changed fpm, fpm_xdebug, build, and deploy container images to use the ones I modified in this PR).

I have installed Magento using the following steps.

docker-compose run --rm deploy composer install
docker-compose run --rm deploy vendor/bin/ece-patches apply
bin/magento-docker ece-deploy

I have browsed the frontend and back office of Magento without any specific trouble.

To contribute that PR, I updated images/php/cli/ and images/php/fpm/. Then I generated the other php versions using ./bin/ece-docker image:generate:php.

I also removed the unused leftover ARG GOSU_VERSION=1.11 in fpm.

Let me know if you have any feedback, questions. Loric

magento-cloud-ft-jenkins-svc commented 3 years ago

Unit & Integration Test Results

:white_check_mark: All unit and integration tests have passed.

Unit Test Output

PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

.....                                                               5 / 5 (100%)

Time: 180 ms, Memory: 12.00 MB

OK (5 tests, 16 assertions)

Generating code coverage report in Clover XML format ... done [441 ms]

Integration Test Output

PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

.............                                                     13 / 13 (100%)

Time: 2.16 seconds, Memory: 30.00 MB

OK (13 tests, 13 assertions)

This comment was generated by Jenkins job magento-cloud-docker/unit build 9.

magento-cloud-ft-jenkins-svc commented 3 years ago

Static Analysis & Code Style Results

:white_check_mark: All static analysis and code style checks have passed.

PHP Codesniffer Output

............................................................ 60 / 89 (67%)
.............................                                89 / 89 (100%)

Time: 3.13 secs; Memory: 10MB

PHP Mess Detector Output


Found 0 violations and 0 errors in 2039ms

[32mNo mess detected[0m

PHPStan Output


 [OK] No errors

This comment was generated by Jenkins job magento-cloud-docker/static build 10.

magento-cloud-ft-jenkins-svc commented 3 years ago

Functional Acceptance Test Results

:x: One or more functional acceptance tests have failed.

PHP 7.2

:white_check_mark: Elasticsearch72Cest
:x: SplitDb72Cest
:x: Acceptance72Cest
:white_check_mark: Services72Cest

PHP 7.3

:x: SplitDb73Cest
:x: Acceptance73Cest
:white_check_mark: Elasticsearch73Cest
:white_check_mark: ServicesCest

PHP 7.4

:white_check_mark: DeveloperCest
:x: SplitDbCest
:white_check_mark: ElasticsearchCest
:x: AcceptanceCest
:x: MailHogCest

Output for failed tests is below. If many tests have failed only the first 5 will be included. If you need additional information please reach out to the Magento Cloud team for more details.

This comment was generated by Jenkins job magento-cloud-docker/functional build 12.

magento-cloud-ft-jenkins-svc commented 3 years ago

PHP 7.2 SplitDb72Cest Output

Codeception PHP Testing Framework v4.1.16
Powered by PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

Acceptance Tests (1) ---------------------------------------
SplitDb72Cest: Test split db on production mode
Signature: Magento\CloudDocker\Test\Functional\Acceptance\SplitDb72Cest:testSplitDbOnProductionMode
Test: src/Test/Functional/Acceptance/SplitDb72Cest.php:testSplitDbOnProductionMode
Scenario --
 I cleanup work dir 
 I is cache work dir exists "2.3.2"
 I clone template to work dir "2.3.2"
 I create auth json 
 I create artifacts dir 
 I create artifact current tested code "docker","1.2.99"
 I add artifacts repo to composer 
 I add dependency to composer "magento/magento-...","1.2.99"
 I add ece tools git repo to composer 
 I add dependency to composer "magento/e...","dev-devel..."
 I composer update 
 I assert true true,"Composer update failed"
 I cache work dir "2.3.2"
sh: rsync: not found
 I read services yaml 
 I read app magento yaml 
 I write services yaml {"mysql":{"type":"mysql:10.2","di...}
 I write app magento yaml {"name":"mymagento","type":"ph...}
 I write env magento yaml {"stage":{"global":{"SCD_ON_DE...}
 I get exposed port 
 I get exposed port "db_quote"
 I get exposed port "db_sales"
 I generate docker compose "--mode=production --expose-d..."
 I replace images with custom 
 I start environment 
 I run docker compose command "run build cloud-build"
 I run docker compose command "run deploy cloud-deploy"
 I am connected to database "db_quote"
 I grab num records "quote_id_mask"
 I stop environment 
 I remove work dir 
 ERROR 

------------------------------------------------------------
13x DEPRECATION: Passing a command as string when creating a "Symfony\Component\Process\Process" instance is deprecated since Symfony 4.2, pass it as an array of its arguments instead, or use the "Process::fromShellCommandline()" constructor if you need features provided by the shell. /app/vendor/symfony/process/Process.php:147
4x DEPRECATION: The Robo\Common\ProcessUtils::escapeArgument() method is a copy of a method that was deprecated by Symfony 3.3 and removed in Symfony 4; it will be removed in Robo 2.0. /app/vendor/consolidation/robo/src/Common/ProcessUtils.php:39

Time: 7.81 minutes, Memory: 16.00 MB

There was 1 error:

---------
1) SplitDb72Cest: Test split db on production mode
 Test  src/Test/Functional/Acceptance/SplitDb72Cest.php:testSplitDbOnProductionMode

  [PDOException] SQLSTATE[42S02]: Base table or view not found: 1146 Table 'magento2.quote_id_mask' doesn't exist  

Scenario Steps:

 30. $I->removeWorkDir() at src/Test/Functional/Acceptance/AbstractCest.php:53
 29. $I->stopEnvironment() at src/Test/Functional/Acceptance/AbstractCest.php:52
 28. $I->grabNumRecords("quote_id_mask") at src/Test/Functional/Acceptance/SplitDbCest.php:72
 27. $I->amConnectedToDatabase("db_quote") at src/Test/Functional/Acceptance/SplitDbCest.php:70
 26. $I->runDockerComposeCommand("run deploy cloud-deploy") at src/Test/Functional/Acceptance/SplitDbCest.php:68
 25. $I->runDockerComposeCommand("run build cloud-build") at src/Test/Functional/Acceptance/SplitDbCest.php:67

#1  Codeception\Module\Db->grabNumRecords
#2  /app/tests/functional/_support/_generated/CliTesterActions.php:1228
#3  /app/src/Test/Functional/Acceptance/SplitDbCest.php:72
#4  Magento\CloudDocker\Test\Functional\Acceptance\SplitDbCest->testSplitDbOnProductionMode

ERRORS!
Tests: 1, Assertions: 1, Errors: 1.
- XML report generated in file:///app/tests/functional/_output/junit.xml

This comment was generated by Jenkins job magento-cloud-docker/functional build 12.

magento-cloud-ft-jenkins-svc commented 3 years ago

PHP 7.2 Acceptance72Cest Output

Codeception PHP Testing Framework v4.1.16
Powered by PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

Acceptance Tests (2) ---------------------------------------
Acceptance72Cest: Test production mode
Signature: Magento\CloudDocker\Test\Functional\Acceptance\Acceptance72Cest:testProductionMode
Test: src/Test/Functional/Acceptance/Acceptance72Cest.php:testProductionMode
Scenario --
 I cleanup work dir 
 I is cache work dir exists "2.3.2"
 I clone template to work dir "2.3.2"
 I create auth json 
 I create artifacts dir 
 I create artifact current tested code "docker","1.2.99"
 I add artifacts repo to composer 
 I add dependency to composer "magento/magento-...","1.2.99"
 I add ece tools git repo to composer 
 I add dependency to composer "magento/e...","dev-devel..."
 I composer update 
 I assert true true,"Composer update failed"
 I cache work dir "2.3.2"
sh: rsync: not found
 I generate docker compose "--mode=production"
 I assert true true,"Command build:compose failed"
 I replace images with custom 
 I start environment 
 I run docker compose command "run build cloud-build"
 I run docker compose command "run deploy cloud-deploy"
 I run docker compose command "run deploy cloud-post-deploy"
 I am on page "/"
 I see "Home page"
 I stop environment 
 I remove work dir 
 FAIL 

Acceptance72Cest: Test custom host
Signature: Magento\CloudDocker\Test\Functional\Acceptance\Acceptance72Cest:testCustomHost
Test: src/Test/Functional/Acceptance/Acceptance72Cest.php:testCustomHost
Scenario --
 I cleanup work dir 
 I is cache work dir exists "2.3.2"
 I clone template to work dir "2.3.2"
 I create auth json 
 I create artifacts dir 
 I create artifact current tested code "docker","1.2.99"
 I add artifacts repo to composer 
 I add dependency to composer "magento/magento-...","1.2.99"
 I add ece tools git repo to composer 
 I add dependency to composer "magento/e...","dev-devel..."
 I composer update 
 I assert true true,"Composer update failed"
 I cache work dir "2.3.2"
sh: rsync: not found
 I update base url "http://magento2.test:8080/"
 I generate docker compose "--mode=production --host=mag..."
 I assert true true,"Command build:compose failed"
 I replace images with custom 
 I start environment 
 I run docker compose command "run build cloud-build"
 I assert true false,"Build phase failed"
 I stop environment 
 I remove work dir 
 FAIL 

------------------------------------------------------------
26x DEPRECATION: Passing a command as string when creating a "Symfony\Component\Process\Process" instance is deprecated since Symfony 4.2, pass it as an array of its arguments instead, or use the "Process::fromShellCommandline()" constructor if you need features provided by the shell. /app/vendor/symfony/process/Process.php:147
8x DEPRECATION: The Robo\Common\ProcessUtils::escapeArgument() method is a copy of a method that was deprecated by Symfony 3.3 and removed in Symfony 4; it will be removed in Robo 2.0. /app/vendor/consolidation/robo/src/Common/ProcessUtils.php:39

Time: 10.04 minutes, Memory: 20.00 MB

There were 2 failures:

---------
1) Acceptance72Cest: Test production mode
 Test  src/Test/Functional/Acceptance/Acceptance72Cest.php:testProductionMode
 Step  See "Home page"
 Fail  Failed asserting that  on page /
-->  Autoload error We can't read some files that are required to run the Magento application. This usually means file permissions are set incorrectly. 
--> contains "Home page".

Scenario Steps:

 24. $I->removeWorkDir() at src/Test/Functional/Acceptance/AbstractCest.php:53
 23. $I->stopEnvironment() at src/Test/Functional/Acceptance/AbstractCest.php:52
 22. $I->see("Home page") at src/Test/Functional/Acceptance/AcceptanceCest.php:30
 21. $I->amOnPage("/") at src/Test/Functional/Acceptance/AcceptanceCest.php:29
 20. $I->runDockerComposeCommand("run deploy cloud-post...") at src/Test/Functional/Acceptance/AcceptanceCest.php:28
 19. $I->runDockerComposeCommand("run deploy cloud-deploy") at src/Test/Functional/Acceptance/AcceptanceCest.php:27

Artifacts:

Html: /app/tests/functional/_output/Magento.CloudDocker.Test.Functional.Acceptance.Acceptance72Cest.testProductionMode.fail.html
Response: /app/tests/functional/_output/Magento.CloudDocker.Test.Functional.Acceptance.Acceptance72Cest.testProductionMode.fail.html

---------
2) Acceptance72Cest: Test custom host
 Test  src/Test/Functional/Acceptance/Acceptance72Cest.php:testCustomHost
 Step  Assert true false,"Build phase failed"
 Fail  Build phase failed
Failed asserting that false is true.

Scenario Steps:

 22. $I->removeWorkDir() at src/Test/Functional/Acceptance/AbstractCest.php:53
 21. $I->stopEnvironment() at src/Test/Functional/Acceptance/AbstractCest.php:52
 20. $I->assertTrue(false,"Build phase failed") at src/Test/Functional/Acceptance/AcceptanceCest.php:49
 19. $I->runDockerComposeCommand("run build cloud-build") at src/Test/Functional/Acceptance/AcceptanceCest.php:49
 18. $I->startEnvironment() at src/Test/Functional/Acceptance/AcceptanceCest.php:48
 17. $I->replaceImagesWithCustom() at src/Test/Functional/Acceptance/AcceptanceCest.php:47

FAILURES!
Tests: 2, Assertions: 6, Failures: 2.
- XML report generated in file:///app/tests/functional/_output/junit.xml

This comment was generated by Jenkins job magento-cloud-docker/functional build 12.

magento-cloud-ft-jenkins-svc commented 3 years ago

PHP 7.3 SplitDb73Cest Output

Codeception PHP Testing Framework v4.1.16
Powered by PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

Acceptance Tests (1) ---------------------------------------
SplitDb73Cest: Test split db on production mode
Signature: Magento\CloudDocker\Test\Functional\Acceptance\SplitDb73Cest:testSplitDbOnProductionMode
Test: src/Test/Functional/Acceptance/SplitDb73Cest.php:testSplitDbOnProductionMode
Scenario --
 I cleanup work dir 
 I is cache work dir exists "2.3.5"
 I clone template to work dir "2.3.5"
 I create auth json 
 I create artifacts dir 
 I create artifact current tested code "docker","1.2.99"
 I add artifacts repo to composer 
 I add dependency to composer "magento/magento-...","1.2.99"
 I add ece tools git repo to composer 
 I add dependency to composer "magento/e...","dev-devel..."
 I composer update 
 I assert true true,"Composer update failed"
 I cache work dir "2.3.5"
sh: rsync: not found
 I read services yaml 
 I read app magento yaml 
 I write services yaml {"mysql":{"type":"mysql:10.2","di...}
 I write app magento yaml {"name":"mymagento","type":"ph...}
 I write env magento yaml {"stage":{"global":{"SCD_ON_DE...}
 I get exposed port 
 I get exposed port "db_quote"
 I get exposed port "db_sales"
 I generate docker compose "--mode=production --expose-d..."
 I replace images with custom 
 I start environment 
 I run docker compose command "run build cloud-build"
 I run docker compose command "run deploy cloud-deploy"
 I am connected to database "db_quote"
 I grab num records "quote_id_mask"
 I stop environment 
 I remove work dir 
 ERROR 

------------------------------------------------------------
13x DEPRECATION: Passing a command as string when creating a "Symfony\Component\Process\Process" instance is deprecated since Symfony 4.2, pass it as an array of its arguments instead, or use the "Process::fromShellCommandline()" constructor if you need features provided by the shell. /app/vendor/symfony/process/Process.php:147
4x DEPRECATION: The Robo\Common\ProcessUtils::escapeArgument() method is a copy of a method that was deprecated by Symfony 3.3 and removed in Symfony 4; it will be removed in Robo 2.0. /app/vendor/consolidation/robo/src/Common/ProcessUtils.php:39

Time: 8.76 minutes, Memory: 18.00 MB

There was 1 error:

---------
1) SplitDb73Cest: Test split db on production mode
 Test  src/Test/Functional/Acceptance/SplitDb73Cest.php:testSplitDbOnProductionMode

  [PDOException] SQLSTATE[42S02]: Base table or view not found: 1146 Table 'magento2.quote_id_mask' doesn't exist  

Scenario Steps:

 30. $I->removeWorkDir() at src/Test/Functional/Acceptance/AbstractCest.php:53
 29. $I->stopEnvironment() at src/Test/Functional/Acceptance/AbstractCest.php:52
 28. $I->grabNumRecords("quote_id_mask") at src/Test/Functional/Acceptance/SplitDbCest.php:72
 27. $I->amConnectedToDatabase("db_quote") at src/Test/Functional/Acceptance/SplitDbCest.php:70
 26. $I->runDockerComposeCommand("run deploy cloud-deploy") at src/Test/Functional/Acceptance/SplitDbCest.php:68
 25. $I->runDockerComposeCommand("run build cloud-build") at src/Test/Functional/Acceptance/SplitDbCest.php:67

#1  Codeception\Module\Db->grabNumRecords
#2  /app/tests/functional/_support/_generated/CliTesterActions.php:1228
#3  /app/src/Test/Functional/Acceptance/SplitDbCest.php:72
#4  Magento\CloudDocker\Test\Functional\Acceptance\SplitDbCest->testSplitDbOnProductionMode

ERRORS!
Tests: 1, Assertions: 1, Errors: 1.
- XML report generated in file:///app/tests/functional/_output/junit.xml

This comment was generated by Jenkins job magento-cloud-docker/functional build 12.

magento-cloud-ft-jenkins-svc commented 3 years ago

PHP 7.3 Acceptance73Cest Output

Codeception PHP Testing Framework v4.1.16
Powered by PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

Acceptance Tests (2) ---------------------------------------
Acceptance73Cest: Test production mode
Signature: Magento\CloudDocker\Test\Functional\Acceptance\Acceptance73Cest:testProductionMode
Test: src/Test/Functional/Acceptance/Acceptance73Cest.php:testProductionMode
Scenario --
 I cleanup work dir 
 I is cache work dir exists "2.3.5"
 I clone template to work dir "2.3.5"
 I create auth json 
 I create artifacts dir 
 I create artifact current tested code "docker","1.2.99"
 I add artifacts repo to composer 
 I add dependency to composer "magento/magento-...","1.2.99"
 I add ece tools git repo to composer 
 I add dependency to composer "magento/e...","dev-devel..."
 I composer update 
 I assert true true,"Composer update failed"
 I cache work dir "2.3.5"
sh: rsync: not found
 I generate docker compose "--mode=production"
 I assert true true,"Command build:compose failed"
 I replace images with custom 
 I start environment 
 I run docker compose command "run build cloud-build"
 I run docker compose command "run deploy cloud-deploy"
 I run docker compose command "run deploy cloud-post-deploy"
 I am on page "/"
 I see "Home page"
 I stop environment 
 I remove work dir 
 FAIL 

Acceptance73Cest: Test custom host
Signature: Magento\CloudDocker\Test\Functional\Acceptance\Acceptance73Cest:testCustomHost
Test: src/Test/Functional/Acceptance/Acceptance73Cest.php:testCustomHost
Scenario --
 I cleanup work dir 
 I is cache work dir exists "2.3.5"
 I clone template to work dir "2.3.5"
 I create auth json 
 I create artifacts dir 
 I create artifact current tested code "docker","1.2.99"
 I add artifacts repo to composer 
 I add dependency to composer "magento/magento-...","1.2.99"
 I add ece tools git repo to composer 
 I add dependency to composer "magento/e...","dev-devel..."
 I composer update 
 I assert true true,"Composer update failed"
 I cache work dir "2.3.5"
sh: rsync: not found
 I update base url "http://magento2.test:8080/"
 I generate docker compose "--mode=production --host=mag..."
 I assert true true,"Command build:compose failed"
 I replace images with custom 
 I start environment 
 I run docker compose command "run build cloud-build"
 I assert true false,"Build phase failed"
 I stop environment 
 I remove work dir 
 FAIL 

------------------------------------------------------------
26x DEPRECATION: Passing a command as string when creating a "Symfony\Component\Process\Process" instance is deprecated since Symfony 4.2, pass it as an array of its arguments instead, or use the "Process::fromShellCommandline()" constructor if you need features provided by the shell. /app/vendor/symfony/process/Process.php:147
8x DEPRECATION: The Robo\Common\ProcessUtils::escapeArgument() method is a copy of a method that was deprecated by Symfony 3.3 and removed in Symfony 4; it will be removed in Robo 2.0. /app/vendor/consolidation/robo/src/Common/ProcessUtils.php:39

Time: 11.12 minutes, Memory: 20.00 MB

There were 2 failures:

---------
1) Acceptance73Cest: Test production mode
 Test  src/Test/Functional/Acceptance/Acceptance73Cest.php:testProductionMode
 Step  See "Home page"
 Fail  Failed asserting that  on page /
-->  Autoload error We can't read some files that are required to run the Magento application. This usually means file permissions are set incorrectly. 
--> contains "Home page".

Scenario Steps:

 24. $I->removeWorkDir() at src/Test/Functional/Acceptance/AbstractCest.php:53
 23. $I->stopEnvironment() at src/Test/Functional/Acceptance/AbstractCest.php:52
 22. $I->see("Home page") at src/Test/Functional/Acceptance/AcceptanceCest.php:30
 21. $I->amOnPage("/") at src/Test/Functional/Acceptance/AcceptanceCest.php:29
 20. $I->runDockerComposeCommand("run deploy cloud-post...") at src/Test/Functional/Acceptance/AcceptanceCest.php:28
 19. $I->runDockerComposeCommand("run deploy cloud-deploy") at src/Test/Functional/Acceptance/AcceptanceCest.php:27

Artifacts:

Html: /app/tests/functional/_output/Magento.CloudDocker.Test.Functional.Acceptance.Acceptance73Cest.testProductionMode.fail.html
Response: /app/tests/functional/_output/Magento.CloudDocker.Test.Functional.Acceptance.Acceptance73Cest.testProductionMode.fail.html

---------
2) Acceptance73Cest: Test custom host
 Test  src/Test/Functional/Acceptance/Acceptance73Cest.php:testCustomHost
 Step  Assert true false,"Build phase failed"
 Fail  Build phase failed
Failed asserting that false is true.

Scenario Steps:

 22. $I->removeWorkDir() at src/Test/Functional/Acceptance/AbstractCest.php:53
 21. $I->stopEnvironment() at src/Test/Functional/Acceptance/AbstractCest.php:52
 20. $I->assertTrue(false,"Build phase failed") at src/Test/Functional/Acceptance/AcceptanceCest.php:49
 19. $I->runDockerComposeCommand("run build cloud-build") at src/Test/Functional/Acceptance/AcceptanceCest.php:49
 18. $I->startEnvironment() at src/Test/Functional/Acceptance/AcceptanceCest.php:48
 17. $I->replaceImagesWithCustom() at src/Test/Functional/Acceptance/AcceptanceCest.php:47

FAILURES!
Tests: 2, Assertions: 6, Failures: 2.
- XML report generated in file:///app/tests/functional/_output/junit.xml

This comment was generated by Jenkins job magento-cloud-docker/functional build 12.

magento-cloud-ft-jenkins-svc commented 3 years ago

PHP 7.4 SplitDbCest Output

Codeception PHP Testing Framework v4.1.16
Powered by PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

Acceptance Tests (1) ---------------------------------------
SplitDbCest: Test split db on production mode
Signature: Magento\CloudDocker\Test\Functional\Acceptance\SplitDbCest:testSplitDbOnProductionMode
Test: src/Test/Functional/Acceptance/SplitDbCest.php:testSplitDbOnProductionMode
Scenario --
 I cleanup work dir 
 I is cache work dir exists "master"
 I clone template to work dir "master"
 I create auth json 
 I create artifacts dir 
 I create artifact current tested code "docker","1.2.99"
 I add artifacts repo to composer 
 I add dependency to composer "magento/magento-...","1.2.99"
 I add ece tools git repo to composer 
 I add dependency to composer "magento/e...","dev-devel..."
 I composer update 
 I assert true true,"Composer update failed"
 I cache work dir "master"
sh: rsync: not found
 I read services yaml 
 I read app magento yaml 
 I write services yaml {"mysql":{"type":"mysql:10.3","di...}
 I write app magento yaml {"name":"mymagento","type":"ph...}
 I write env magento yaml {"stage":{"global":{"SCD_ON_DE...}
 I get exposed port 
 I get exposed port "db_quote"
 I get exposed port "db_sales"
 I generate docker compose "--mode=production --expose-d..."
 I replace images with custom 
 I start environment 
 I run docker compose command "run build cloud-build"
 I run docker compose command "run deploy cloud-deploy"
 I am connected to database "db_quote"
 I grab num records "quote_id_mask"
 I stop environment 
 I remove work dir 
 ERROR 

------------------------------------------------------------
13x DEPRECATION: Passing a command as string when creating a "Symfony\Component\Process\Process" instance is deprecated since Symfony 4.2, pass it as an array of its arguments instead, or use the "Process::fromShellCommandline()" constructor if you need features provided by the shell. /app/vendor/symfony/process/Process.php:147
4x DEPRECATION: The Robo\Common\ProcessUtils::escapeArgument() method is a copy of a method that was deprecated by Symfony 3.3 and removed in Symfony 4; it will be removed in Robo 2.0. /app/vendor/consolidation/robo/src/Common/ProcessUtils.php:39

Time: 8.81 minutes, Memory: 16.00 MB

There was 1 error:

---------
1) SplitDbCest: Test split db on production mode
 Test  src/Test/Functional/Acceptance/SplitDbCest.php:testSplitDbOnProductionMode

  [PDOException] SQLSTATE[42S02]: Base table or view not found: 1146 Table 'magento2.quote_id_mask' doesn't exist  

Scenario Steps:

 30. $I->removeWorkDir() at src/Test/Functional/Acceptance/AbstractCest.php:53
 29. $I->stopEnvironment() at src/Test/Functional/Acceptance/AbstractCest.php:52
 28. $I->grabNumRecords("quote_id_mask") at src/Test/Functional/Acceptance/SplitDbCest.php:72
 27. $I->amConnectedToDatabase("db_quote") at src/Test/Functional/Acceptance/SplitDbCest.php:70
 26. $I->runDockerComposeCommand("run deploy cloud-deploy") at src/Test/Functional/Acceptance/SplitDbCest.php:68
 25. $I->runDockerComposeCommand("run build cloud-build") at src/Test/Functional/Acceptance/SplitDbCest.php:67

#1  Codeception\Module\Db->grabNumRecords
#2  /app/tests/functional/_support/_generated/CliTesterActions.php:1228
#3  /app/src/Test/Functional/Acceptance/SplitDbCest.php:72
#4  Magento\CloudDocker\Test\Functional\Acceptance\SplitDbCest->testSplitDbOnProductionMode

ERRORS!
Tests: 1, Assertions: 1, Errors: 1.
- XML report generated in file:///app/tests/functional/_output/junit.xml

This comment was generated by Jenkins job magento-cloud-docker/functional build 12.

magento-cloud-ft-jenkins-svc commented 3 years ago

Unit & Integration Test Results

:white_check_mark: All unit and integration tests have passed.

Unit Test Output

PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

.....                                                               5 / 5 (100%)

Time: 319 ms, Memory: 12.00 MB

OK (5 tests, 16 assertions)

Generating code coverage report in Clover XML format ... done [783 ms]

Integration Test Output

PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

.............                                                     13 / 13 (100%)

Time: 2.91 seconds, Memory: 30.00 MB

OK (13 tests, 13 assertions)

This comment was generated by Jenkins job magento-cloud-docker/unit build 10.

magento-cloud-ft-jenkins-svc commented 3 years ago

Static Analysis & Code Style Results

:white_check_mark: All static analysis and code style checks have passed.

PHP Codesniffer Output

............................................................ 60 / 89 (67%)
.............................                                89 / 89 (100%)

Time: 4.68 secs; Memory: 10MB

PHP Mess Detector Output


Found 0 violations and 0 errors in 2179ms

[32mNo mess detected[0m

PHPStan Output


 [OK] No errors

This comment was generated by Jenkins job magento-cloud-docker/static build 11.

magento-cloud-ft-jenkins-svc commented 3 years ago

Functional Acceptance Test Results

:x: One or more functional acceptance tests have failed.

PHP 7.2

:white_check_mark: Elasticsearch72Cest
:x: SplitDb72Cest
:white_check_mark: Services72Cest
:x: Acceptance72Cest

PHP 7.3

:x: SplitDb73Cest
:x: Acceptance73Cest
:white_check_mark: Elasticsearch73Cest
:white_check_mark: ServicesCest

PHP 7.4

:white_check_mark: DeveloperCest
:x: SplitDbCest
:x: AcceptanceCest
:x: MailHogCest
:white_check_mark: ElasticsearchCest

Output for failed tests is below. If many tests have failed only the first 5 will be included. If you need additional information please reach out to the Magento Cloud team for more details.

This comment was generated by Jenkins job magento-cloud-docker/functional build 13.

magento-cloud-ft-jenkins-svc commented 3 years ago

PHP 7.2 SplitDb72Cest Output

Codeception PHP Testing Framework v4.1.16
Powered by PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

Acceptance Tests (1) ---------------------------------------
SplitDb72Cest: Test split db on production mode
Signature: Magento\CloudDocker\Test\Functional\Acceptance\SplitDb72Cest:testSplitDbOnProductionMode
Test: src/Test/Functional/Acceptance/SplitDb72Cest.php:testSplitDbOnProductionMode
Scenario --
 I cleanup work dir 
 I is cache work dir exists "2.3.2"
 I clone template to work dir "2.3.2"
 I create auth json 
 I create artifacts dir 
 I create artifact current tested code "docker","1.2.99"
 I add artifacts repo to composer 
 I add dependency to composer "magento/magento-...","1.2.99"
 I add ece tools git repo to composer 
 I add dependency to composer "magento/e...","dev-devel..."
 I composer update 
 I assert true true,"Composer update failed"
 I cache work dir "2.3.2"
sh: rsync: not found
 I read services yaml 
 I read app magento yaml 
 I write services yaml {"mysql":{"type":"mysql:10.2","di...}
 I write app magento yaml {"name":"mymagento","type":"ph...}
 I write env magento yaml {"stage":{"global":{"SCD_ON_DE...}
 I get exposed port 
 I get exposed port "db_quote"
 I get exposed port "db_sales"
 I generate docker compose "--mode=production --expose-d..."
 I replace images with custom 
 I start environment 
 I run docker compose command "run build cloud-build"
 I run docker compose command "run deploy cloud-deploy"
 I am connected to database "db_quote"
 I grab num records "quote_id_mask"
 I stop environment 
 I remove work dir 
 ERROR 

------------------------------------------------------------
13x DEPRECATION: Passing a command as string when creating a "Symfony\Component\Process\Process" instance is deprecated since Symfony 4.2, pass it as an array of its arguments instead, or use the "Process::fromShellCommandline()" constructor if you need features provided by the shell. /app/vendor/symfony/process/Process.php:147
4x DEPRECATION: The Robo\Common\ProcessUtils::escapeArgument() method is a copy of a method that was deprecated by Symfony 3.3 and removed in Symfony 4; it will be removed in Robo 2.0. /app/vendor/consolidation/robo/src/Common/ProcessUtils.php:39

Time: 8.19 minutes, Memory: 16.00 MB

There was 1 error:

---------
1) SplitDb72Cest: Test split db on production mode
 Test  src/Test/Functional/Acceptance/SplitDb72Cest.php:testSplitDbOnProductionMode

  [PDOException] SQLSTATE[42S02]: Base table or view not found: 1146 Table 'magento2.quote_id_mask' doesn't exist  

Scenario Steps:

 30. $I->removeWorkDir() at src/Test/Functional/Acceptance/AbstractCest.php:53
 29. $I->stopEnvironment() at src/Test/Functional/Acceptance/AbstractCest.php:52
 28. $I->grabNumRecords("quote_id_mask") at src/Test/Functional/Acceptance/SplitDbCest.php:72
 27. $I->amConnectedToDatabase("db_quote") at src/Test/Functional/Acceptance/SplitDbCest.php:70
 26. $I->runDockerComposeCommand("run deploy cloud-deploy") at src/Test/Functional/Acceptance/SplitDbCest.php:68
 25. $I->runDockerComposeCommand("run build cloud-build") at src/Test/Functional/Acceptance/SplitDbCest.php:67

#1  Codeception\Module\Db->grabNumRecords
#2  /app/tests/functional/_support/_generated/CliTesterActions.php:1228
#3  /app/src/Test/Functional/Acceptance/SplitDbCest.php:72
#4  Magento\CloudDocker\Test\Functional\Acceptance\SplitDbCest->testSplitDbOnProductionMode

ERRORS!
Tests: 1, Assertions: 1, Errors: 1.
- XML report generated in file:///app/tests/functional/_output/junit.xml

This comment was generated by Jenkins job magento-cloud-docker/functional build 13.

magento-cloud-ft-jenkins-svc commented 3 years ago

PHP 7.2 Acceptance72Cest Output

Codeception PHP Testing Framework v4.1.16
Powered by PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

Acceptance Tests (2) ---------------------------------------
Acceptance72Cest: Test production mode
Signature: Magento\CloudDocker\Test\Functional\Acceptance\Acceptance72Cest:testProductionMode
Test: src/Test/Functional/Acceptance/Acceptance72Cest.php:testProductionMode
Scenario --
 I cleanup work dir 
 I is cache work dir exists "2.3.2"
 I clone template to work dir "2.3.2"
 I create auth json 
 I create artifacts dir 
 I create artifact current tested code "docker","1.2.99"
 I add artifacts repo to composer 
 I add dependency to composer "magento/magento-...","1.2.99"
 I add ece tools git repo to composer 
 I add dependency to composer "magento/e...","dev-devel..."
 I composer update 
 I assert true true,"Composer update failed"
 I cache work dir "2.3.2"
sh: rsync: not found
 I generate docker compose "--mode=production"
 I assert true true,"Command build:compose failed"
 I replace images with custom 
 I start environment 
 I run docker compose command "run build cloud-build"
 I run docker compose command "run deploy cloud-deploy"
 I run docker compose command "run deploy cloud-post-deploy"
 I am on page "/"
 I see "Home page"
 I stop environment 
 I remove work dir 
 FAIL 

Acceptance72Cest: Test custom host
Signature: Magento\CloudDocker\Test\Functional\Acceptance\Acceptance72Cest:testCustomHost
Test: src/Test/Functional/Acceptance/Acceptance72Cest.php:testCustomHost
Scenario --
 I cleanup work dir 
 I is cache work dir exists "2.3.2"
 I clone template to work dir "2.3.2"
 I create auth json 
 I create artifacts dir 
 I create artifact current tested code "docker","1.2.99"
 I add artifacts repo to composer 
 I add dependency to composer "magento/magento-...","1.2.99"
 I add ece tools git repo to composer 
 I add dependency to composer "magento/e...","dev-devel..."
 I composer update 
 I assert true true,"Composer update failed"
 I cache work dir "2.3.2"
sh: rsync: not found
 I update base url "http://magento2.test:8080/"
 I generate docker compose "--mode=production --host=mag..."
 I assert true true,"Command build:compose failed"
 I replace images with custom 
 I start environment 
 I run docker compose command "run build cloud-build"
 I assert true false,"Build phase failed"
 I stop environment 
 I remove work dir 
 FAIL 

------------------------------------------------------------
26x DEPRECATION: Passing a command as string when creating a "Symfony\Component\Process\Process" instance is deprecated since Symfony 4.2, pass it as an array of its arguments instead, or use the "Process::fromShellCommandline()" constructor if you need features provided by the shell. /app/vendor/symfony/process/Process.php:147
8x DEPRECATION: The Robo\Common\ProcessUtils::escapeArgument() method is a copy of a method that was deprecated by Symfony 3.3 and removed in Symfony 4; it will be removed in Robo 2.0. /app/vendor/consolidation/robo/src/Common/ProcessUtils.php:39

Time: 11.44 minutes, Memory: 20.00 MB

There were 2 failures:

---------
1) Acceptance72Cest: Test production mode
 Test  src/Test/Functional/Acceptance/Acceptance72Cest.php:testProductionMode
 Step  See "Home page"
 Fail  Failed asserting that  on page /
-->  Autoload error We can't read some files that are required to run the Magento application. This usually means file permissions are set incorrectly. 
--> contains "Home page".

Scenario Steps:

 24. $I->removeWorkDir() at src/Test/Functional/Acceptance/AbstractCest.php:53
 23. $I->stopEnvironment() at src/Test/Functional/Acceptance/AbstractCest.php:52
 22. $I->see("Home page") at src/Test/Functional/Acceptance/AcceptanceCest.php:30
 21. $I->amOnPage("/") at src/Test/Functional/Acceptance/AcceptanceCest.php:29
 20. $I->runDockerComposeCommand("run deploy cloud-post...") at src/Test/Functional/Acceptance/AcceptanceCest.php:28
 19. $I->runDockerComposeCommand("run deploy cloud-deploy") at src/Test/Functional/Acceptance/AcceptanceCest.php:27

Artifacts:

Html: /app/tests/functional/_output/Magento.CloudDocker.Test.Functional.Acceptance.Acceptance72Cest.testProductionMode.fail.html
Response: /app/tests/functional/_output/Magento.CloudDocker.Test.Functional.Acceptance.Acceptance72Cest.testProductionMode.fail.html

---------
2) Acceptance72Cest: Test custom host
 Test  src/Test/Functional/Acceptance/Acceptance72Cest.php:testCustomHost
 Step  Assert true false,"Build phase failed"
 Fail  Build phase failed
Failed asserting that false is true.

Scenario Steps:

 22. $I->removeWorkDir() at src/Test/Functional/Acceptance/AbstractCest.php:53
 21. $I->stopEnvironment() at src/Test/Functional/Acceptance/AbstractCest.php:52
 20. $I->assertTrue(false,"Build phase failed") at src/Test/Functional/Acceptance/AcceptanceCest.php:49
 19. $I->runDockerComposeCommand("run build cloud-build") at src/Test/Functional/Acceptance/AcceptanceCest.php:49
 18. $I->startEnvironment() at src/Test/Functional/Acceptance/AcceptanceCest.php:48
 17. $I->replaceImagesWithCustom() at src/Test/Functional/Acceptance/AcceptanceCest.php:47

FAILURES!
Tests: 2, Assertions: 6, Failures: 2.
- XML report generated in file:///app/tests/functional/_output/junit.xml

This comment was generated by Jenkins job magento-cloud-docker/functional build 13.

magento-cloud-ft-jenkins-svc commented 3 years ago

PHP 7.3 SplitDb73Cest Output

Codeception PHP Testing Framework v4.1.16
Powered by PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

Acceptance Tests (1) ---------------------------------------
SplitDb73Cest: Test split db on production mode
Signature: Magento\CloudDocker\Test\Functional\Acceptance\SplitDb73Cest:testSplitDbOnProductionMode
Test: src/Test/Functional/Acceptance/SplitDb73Cest.php:testSplitDbOnProductionMode
Scenario --
 I cleanup work dir 
 I is cache work dir exists "2.3.5"
 I clone template to work dir "2.3.5"
 I create auth json 
 I create artifacts dir 
 I create artifact current tested code "docker","1.2.99"
 I add artifacts repo to composer 
 I add dependency to composer "magento/magento-...","1.2.99"
 I add ece tools git repo to composer 
 I add dependency to composer "magento/e...","dev-devel..."
 I composer update 
 I assert true true,"Composer update failed"
 I cache work dir "2.3.5"
sh: rsync: not found
 I read services yaml 
 I read app magento yaml 
 I write services yaml {"mysql":{"type":"mysql:10.2","di...}
 I write app magento yaml {"name":"mymagento","type":"ph...}
 I write env magento yaml {"stage":{"global":{"SCD_ON_DE...}
 I get exposed port 
 I get exposed port "db_quote"
 I get exposed port "db_sales"
 I generate docker compose "--mode=production --expose-d..."
 I replace images with custom 
 I start environment 
 I run docker compose command "run build cloud-build"
 I run docker compose command "run deploy cloud-deploy"
 I am connected to database "db_quote"
 I grab num records "quote_id_mask"
 I stop environment 
 I remove work dir 
 ERROR 

------------------------------------------------------------
13x DEPRECATION: Passing a command as string when creating a "Symfony\Component\Process\Process" instance is deprecated since Symfony 4.2, pass it as an array of its arguments instead, or use the "Process::fromShellCommandline()" constructor if you need features provided by the shell. /app/vendor/symfony/process/Process.php:147
4x DEPRECATION: The Robo\Common\ProcessUtils::escapeArgument() method is a copy of a method that was deprecated by Symfony 3.3 and removed in Symfony 4; it will be removed in Robo 2.0. /app/vendor/consolidation/robo/src/Common/ProcessUtils.php:39

Time: 7.27 minutes, Memory: 16.00 MB

There was 1 error:

---------
1) SplitDb73Cest: Test split db on production mode
 Test  src/Test/Functional/Acceptance/SplitDb73Cest.php:testSplitDbOnProductionMode

  [PDOException] SQLSTATE[42S02]: Base table or view not found: 1146 Table 'magento2.quote_id_mask' doesn't exist  

Scenario Steps:

 30. $I->removeWorkDir() at src/Test/Functional/Acceptance/AbstractCest.php:53
 29. $I->stopEnvironment() at src/Test/Functional/Acceptance/AbstractCest.php:52
 28. $I->grabNumRecords("quote_id_mask") at src/Test/Functional/Acceptance/SplitDbCest.php:72
 27. $I->amConnectedToDatabase("db_quote") at src/Test/Functional/Acceptance/SplitDbCest.php:70
 26. $I->runDockerComposeCommand("run deploy cloud-deploy") at src/Test/Functional/Acceptance/SplitDbCest.php:68
 25. $I->runDockerComposeCommand("run build cloud-build") at src/Test/Functional/Acceptance/SplitDbCest.php:67

#1  Codeception\Module\Db->grabNumRecords
#2  /app/tests/functional/_support/_generated/CliTesterActions.php:1228
#3  /app/src/Test/Functional/Acceptance/SplitDbCest.php:72
#4  Magento\CloudDocker\Test\Functional\Acceptance\SplitDbCest->testSplitDbOnProductionMode

ERRORS!
Tests: 1, Assertions: 1, Errors: 1.
- XML report generated in file:///app/tests/functional/_output/junit.xml

This comment was generated by Jenkins job magento-cloud-docker/functional build 13.

magento-cloud-ft-jenkins-svc commented 3 years ago

PHP 7.3 Acceptance73Cest Output

Codeception PHP Testing Framework v4.1.16
Powered by PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

Acceptance Tests (2) ---------------------------------------
Acceptance73Cest: Test production mode
Signature: Magento\CloudDocker\Test\Functional\Acceptance\Acceptance73Cest:testProductionMode
Test: src/Test/Functional/Acceptance/Acceptance73Cest.php:testProductionMode
Scenario --
 I cleanup work dir 
 I is cache work dir exists "2.3.5"
 I clone template to work dir "2.3.5"
 I create auth json 
 I create artifacts dir 
 I create artifact current tested code "docker","1.2.99"
 I add artifacts repo to composer 
 I add dependency to composer "magento/magento-...","1.2.99"
 I add ece tools git repo to composer 
 I add dependency to composer "magento/e...","dev-devel..."
 I composer update 
 I assert true true,"Composer update failed"
 I cache work dir "2.3.5"
sh: rsync: not found
 I generate docker compose "--mode=production"
 I assert true true,"Command build:compose failed"
 I replace images with custom 
 I start environment 
 I run docker compose command "run build cloud-build"
 I run docker compose command "run deploy cloud-deploy"
 I run docker compose command "run deploy cloud-post-deploy"
 I am on page "/"
 I see "Home page"
 I stop environment 
 I remove work dir 
 FAIL 

Acceptance73Cest: Test custom host
Signature: Magento\CloudDocker\Test\Functional\Acceptance\Acceptance73Cest:testCustomHost
Test: src/Test/Functional/Acceptance/Acceptance73Cest.php:testCustomHost
Scenario --
 I cleanup work dir 
 I is cache work dir exists "2.3.5"
 I clone template to work dir "2.3.5"
 I create auth json 
 I create artifacts dir 
 I create artifact current tested code "docker","1.2.99"
 I add artifacts repo to composer 
 I add dependency to composer "magento/magento-...","1.2.99"
 I add ece tools git repo to composer 
 I add dependency to composer "magento/e...","dev-devel..."
 I composer update 
 I assert true true,"Composer update failed"
 I cache work dir "2.3.5"
sh: rsync: not found
 I update base url "http://magento2.test:8080/"
 I generate docker compose "--mode=production --host=mag..."
 I assert true true,"Command build:compose failed"
 I replace images with custom 
 I start environment 
 I run docker compose command "run build cloud-build"
 I assert true false,"Build phase failed"
 I stop environment 
 I remove work dir 
 FAIL 

------------------------------------------------------------
26x DEPRECATION: Passing a command as string when creating a "Symfony\Component\Process\Process" instance is deprecated since Symfony 4.2, pass it as an array of its arguments instead, or use the "Process::fromShellCommandline()" constructor if you need features provided by the shell. /app/vendor/symfony/process/Process.php:147
8x DEPRECATION: The Robo\Common\ProcessUtils::escapeArgument() method is a copy of a method that was deprecated by Symfony 3.3 and removed in Symfony 4; it will be removed in Robo 2.0. /app/vendor/consolidation/robo/src/Common/ProcessUtils.php:39

Time: 11.5 minutes, Memory: 20.00 MB

There were 2 failures:

---------
1) Acceptance73Cest: Test production mode
 Test  src/Test/Functional/Acceptance/Acceptance73Cest.php:testProductionMode
 Step  See "Home page"
 Fail  Failed asserting that  on page /
-->  Autoload error We can't read some files that are required to run the Magento application. This usually means file permissions are set incorrectly. 
--> contains "Home page".

Scenario Steps:

 24. $I->removeWorkDir() at src/Test/Functional/Acceptance/AbstractCest.php:53
 23. $I->stopEnvironment() at src/Test/Functional/Acceptance/AbstractCest.php:52
 22. $I->see("Home page") at src/Test/Functional/Acceptance/AcceptanceCest.php:30
 21. $I->amOnPage("/") at src/Test/Functional/Acceptance/AcceptanceCest.php:29
 20. $I->runDockerComposeCommand("run deploy cloud-post...") at src/Test/Functional/Acceptance/AcceptanceCest.php:28
 19. $I->runDockerComposeCommand("run deploy cloud-deploy") at src/Test/Functional/Acceptance/AcceptanceCest.php:27

Artifacts:

Html: /app/tests/functional/_output/Magento.CloudDocker.Test.Functional.Acceptance.Acceptance73Cest.testProductionMode.fail.html
Response: /app/tests/functional/_output/Magento.CloudDocker.Test.Functional.Acceptance.Acceptance73Cest.testProductionMode.fail.html

---------
2) Acceptance73Cest: Test custom host
 Test  src/Test/Functional/Acceptance/Acceptance73Cest.php:testCustomHost
 Step  Assert true false,"Build phase failed"
 Fail  Build phase failed
Failed asserting that false is true.

Scenario Steps:

 22. $I->removeWorkDir() at src/Test/Functional/Acceptance/AbstractCest.php:53
 21. $I->stopEnvironment() at src/Test/Functional/Acceptance/AbstractCest.php:52
 20. $I->assertTrue(false,"Build phase failed") at src/Test/Functional/Acceptance/AcceptanceCest.php:49
 19. $I->runDockerComposeCommand("run build cloud-build") at src/Test/Functional/Acceptance/AcceptanceCest.php:49
 18. $I->startEnvironment() at src/Test/Functional/Acceptance/AcceptanceCest.php:48
 17. $I->replaceImagesWithCustom() at src/Test/Functional/Acceptance/AcceptanceCest.php:47

FAILURES!
Tests: 2, Assertions: 6, Failures: 2.
- XML report generated in file:///app/tests/functional/_output/junit.xml

This comment was generated by Jenkins job magento-cloud-docker/functional build 13.

magento-cloud-ft-jenkins-svc commented 3 years ago

PHP 7.4 SplitDbCest Output

Codeception PHP Testing Framework v4.1.16
Powered by PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

Acceptance Tests (1) ---------------------------------------
SplitDbCest: Test split db on production mode
Signature: Magento\CloudDocker\Test\Functional\Acceptance\SplitDbCest:testSplitDbOnProductionMode
Test: src/Test/Functional/Acceptance/SplitDbCest.php:testSplitDbOnProductionMode
Scenario --
 I cleanup work dir 
 I is cache work dir exists "master"
 I clone template to work dir "master"
 I create auth json 
 I create artifacts dir 
 I create artifact current tested code "docker","1.2.99"
 I add artifacts repo to composer 
 I add dependency to composer "magento/magento-...","1.2.99"
 I add ece tools git repo to composer 
 I add dependency to composer "magento/e...","dev-devel..."
 I composer update 
 I assert true true,"Composer update failed"
 I cache work dir "master"
sh: rsync: not found
 I read services yaml 
 I read app magento yaml 
 I write services yaml {"mysql":{"type":"mysql:10.3","di...}
 I write app magento yaml {"name":"mymagento","type":"ph...}
 I write env magento yaml {"stage":{"global":{"SCD_ON_DE...}
 I get exposed port 
 I get exposed port "db_quote"
 I get exposed port "db_sales"
 I generate docker compose "--mode=production --expose-d..."
 I replace images with custom 
 I start environment 
 I run docker compose command "run build cloud-build"
 I run docker compose command "run deploy cloud-deploy"
 I am connected to database "db_quote"
 I grab num records "quote_id_mask"
 I stop environment 
 I remove work dir 
 ERROR 

------------------------------------------------------------
13x DEPRECATION: Passing a command as string when creating a "Symfony\Component\Process\Process" instance is deprecated since Symfony 4.2, pass it as an array of its arguments instead, or use the "Process::fromShellCommandline()" constructor if you need features provided by the shell. /app/vendor/symfony/process/Process.php:147
4x DEPRECATION: The Robo\Common\ProcessUtils::escapeArgument() method is a copy of a method that was deprecated by Symfony 3.3 and removed in Symfony 4; it will be removed in Robo 2.0. /app/vendor/consolidation/robo/src/Common/ProcessUtils.php:39

Time: 9.66 minutes, Memory: 16.00 MB

There was 1 error:

---------
1) SplitDbCest: Test split db on production mode
 Test  src/Test/Functional/Acceptance/SplitDbCest.php:testSplitDbOnProductionMode

  [PDOException] SQLSTATE[42S02]: Base table or view not found: 1146 Table 'magento2.quote_id_mask' doesn't exist  

Scenario Steps:

 30. $I->removeWorkDir() at src/Test/Functional/Acceptance/AbstractCest.php:53
 29. $I->stopEnvironment() at src/Test/Functional/Acceptance/AbstractCest.php:52
 28. $I->grabNumRecords("quote_id_mask") at src/Test/Functional/Acceptance/SplitDbCest.php:72
 27. $I->amConnectedToDatabase("db_quote") at src/Test/Functional/Acceptance/SplitDbCest.php:70
 26. $I->runDockerComposeCommand("run deploy cloud-deploy") at src/Test/Functional/Acceptance/SplitDbCest.php:68
 25. $I->runDockerComposeCommand("run build cloud-build") at src/Test/Functional/Acceptance/SplitDbCest.php:67

#1  Codeception\Module\Db->grabNumRecords
#2  /app/tests/functional/_support/_generated/CliTesterActions.php:1228
#3  /app/src/Test/Functional/Acceptance/SplitDbCest.php:72
#4  Magento\CloudDocker\Test\Functional\Acceptance\SplitDbCest->testSplitDbOnProductionMode

ERRORS!
Tests: 1, Assertions: 1, Errors: 1.
- XML report generated in file:///app/tests/functional/_output/junit.xml

This comment was generated by Jenkins job magento-cloud-docker/functional build 13.

NadiyaS commented 3 years ago

@magento import pr to magento-commerce/magento-cloud-docker

magento-engcom-team commented 3 years ago

@NadiyaS the pull request successfully imported.

shiftedreality commented 3 years ago

@lobre what about Mutagen and docker-sync? Should we add www user there?

lobre commented 3 years ago

@lobre what about Mutagen and docker-sync? Should we add www user there?

I am not sure there is anything to change about Mutagen and docker-sync. We are not using it in our team, but if I understand correctly how it is supposed to work, those tools should be installed locally on the machine. And each of them has dedicated configurations to handle permissions/user.

Mutagen

https://mutagen.io/documentation/introduction/configuration

permissions:
      defaultFileMode: ...
      defaultDirectoryMode: ...
      defaultOwner: ...
      defaultGroup: ...

docker-sync

https://docker-sync.readthedocs.io/en/latest/getting-started/configuration.html#sync-userid https://docker-sync.readthedocs.io/en/latest/getting-started/configuration.html#sync-groupid

So to me, those values should be configured with the same UID/GID as the local filesystem to avoid messing up with permissions. I cannot find a clear indication in both documentations but I guess that is the default behavior when they are not set.

And I am not sure we can anyway pre-configure those values for developers, as it depends on their local filesystem and as it should be configured either in:

mutagen.sh or
docker-sync.yml.

Is there anything I could be missing? Thanks.

BaDos commented 3 years ago

@lobre Hi! Do you use Linux for testing these changes?

Functional tests are red. I'm trying to reproduce it and I'm facing the permission problem. All phases does not work. And I see that some files and directories are owned by the root user.

I use MacOS, and my UID and GUI are not 1000 The same problem on Jenkins.

drwxr-xr-x 50 www  www    1600 Feb  1 17:52 .
drwxr-xr-x  1 root root   4096 Feb  1 17:55 ..
drwxr-xr-x  9 www  www     288 Feb  1 17:52 .docker
drwxr-xr-x 13 www  www     416 Feb  1 17:54 .git
drwxr-xr-x  8 www  www     256 Feb  1 17:51 .github
-rw-r--r--  1 www  www     358 Feb  1 17:49 .gitignore
-rw-r--r--  1 www  www   12076 Feb  1 17:51 .htaccess
-rw-r--r--  1 www  www   11600 Feb  1 17:51 .htaccess.sample
drwxr-xr-x  4 www  www     128 Feb  1 17:49 .magento
-rw-r--r--  1 www  www    3291 Feb  1 17:49 .magento.app.yaml
-rw-r--r--  1 www  www   26313 Feb  1 17:52 .magento.env.md
-rw-r--r--  1 www  www    1654 Feb  1 17:51 .php_cs.dist
-rw-r--r--  1 www  www    2095 Feb  1 17:51 .travis.yml
-rw-r--r--  1 www  www     101 Feb  1 17:51 .user.ini
-rw-r--r--  1 www  www  544975 Feb  1 17:51 CHANGELOG.md
-rw-r--r--  1 www  www     650 Feb  1 17:51 COPYING.txt
-rw-r--r--  1 www  www    2994 Feb  1 17:51 Gruntfile.js.sample
-rw-r--r--  1 www  www   10364 Feb  1 17:51 LICENSE.txt
-rw-r--r--  1 www  www   10376 Feb  1 17:51 LICENSE_AFL.txt
-rw-r--r--  1 www  www   30634 Feb  1 17:52 LICENSE_EE.txt
-rw-r--r--  1 www  www    3669 Feb  1 17:49 README.md
-rw-r--r--  1 www  www    2657 Feb  1 17:52 README_EE.md
drwxr-xr-x  8 www  www     256 Feb  1 17:51 app
drwxr-xr-x  3 www  www      96 Feb  1 17:49 artifacts
-rw-r--r--  1 www  www     203 Feb  1 17:49 auth.json
-rw-r--r--  1 www  www     150 Feb  1 17:51 auth.json.sample
drwxr-xr-x  5 www  www     160 Feb  1 17:52 bin
-rw-r--r--  1 www  www    3133 Feb  1 17:49 composer.json
-rw-r--r--  1 www  www  761384 Feb  1 17:51 composer.lock
drwxr-xr-x  6 www  www     192 Feb  1 17:52 dev
-rw-r--r--  1 www  www    6273 Feb  1 17:52 docker-compose.yml
-rw-r--r--  1 www  www     265 Feb  1 17:52 docker-sync.yml
drwxr-xr-x  2 root root   4096 Feb  1 17:52 generated
-rw-r--r--  1 www  www      57 Feb  1 17:52 grunt-config.json.sample
-rw-r--r--  1 www  www    1370 Feb  1 17:52 index.php
drwxr-xr-x  5 www  www     160 Feb  1 17:52 lib
drwxr-xr-x  3 www  www      96 Feb  1 17:49 m2-hotfixes
-rw-r--r--  1 www  www     527 Feb  1 17:49 magento-vars.php
-rwxr-xr-x  1 www  www     915 Feb  1 17:52 mutagen.sh
-rw-r--r--  1 www  www    5742 Feb  1 17:52 nginx.conf.sample
-rw-r--r--  1 www  www      82 Feb  1 17:49 op-exclude.txt
-rw-r--r--  1 www  www    1416 Feb  1 17:52 package.json.sample
-rw-r--r--  1 root root     69 Feb  1 17:52 php.dev.ini
-rw-r--r--  1 www  www     707 Feb  1 17:49 php.ini
drwxr-xr-x  5 www  www     160 Feb  1 17:52 phpserver
drwxr-xr-x 13 www  www     416 Feb  1 17:52 pub
drwxr-xr-x  9 www  www     288 Feb  1 17:52 setup
drwxr-xr-x  3 www  www      96 Feb  1 17:49 update
drwxr-xr-x  5 www  www     160 Feb  1 17:52 var
drwxr-xr-x  2 root root   4096 Feb  1 17:52 vendor

BaDos commented 3 years ago

@lobre I rechecked it on my Linux machine, there is the same issue.

lobre commented 3 years ago

Hi @BaDos, I used the stack generated in the context of our MCC project for testing. And yes, I use Linux.

So there are apparently differences between the stack I used and the tests you run in that specific repository. I did not realize there were functional tests on that project, sorry for that. Do you have guidance/documentation on how to execute them so I can debug that issue?

I'll try anyway to dig and fix it tomorrow. Thanks.

lobre commented 3 years ago

I tried today to launch functional tests on my local Linux machines without success. I am not sure to understand exactly how to run them. Here is what I did.

Re-cloned from scratch

Re-cloned my fork to start clean from scratch: git clone https://github.com/lobre/magento-cloud-docker.git. Checked-out my branch: git checkout php-as-www.

Installed composer dependencies

I installed composer dependencies in the repo.

composer install

Had a look at the Travis script

As I am not super comfortable with Codeception, I started with .travis.yml and saw that functional tests were launched using ./tests/travis/functional.sh.

And before executing that script, a codeception.yml is created from codeception.dist.yml.

...
if [ $TEST_SUITE == "functional" ]; then cp codeception.dist.yml codeception.yml && sed -i "s/use_custom_images:\ false/use_custom_images:\ true/" codeception.yml; fi;
...

So I did the same step on my local machine:

cp codeception.dist.yml codeception.yml && sed -i "s/use_custom_images:\ false/use_custom_images:\ true/" codeception.yml;

And then I executed tests the same for php 7.4 as in ./tests/travis/functional.sh with:

./vendor/bin/codecept run -g php74 --steps

But in the functional test, the step with composer did not work because of a bad auth.json.

$ cat _workdir/auth.json
{"http-basic":{"repo.magento.com":{"username":"%REPO_USERNAME%","password":"%REPO_PASSWORD%"}},"github-oauth":{"github.com":"%GITHUB_TOKEN%"}}

I apparently needed to declare those placeholder values as environment variables. So I gathered a Github token, a Magento username, and password and launched instead:

REPO_USERNAME=xxxxxx REPO_PASSWORD=xxxxxx GITHUB_TOKEN=xxxxxx TRAVIS_BUILD_NUMBER=fake-value ./vendor/bin/codecept run -g php73 --steps

Now it goes a little bit farther but composer still exits with error code 2 when executing:

[Composer\Update] Updating Packages: composer update --ansi
[Composer\Update] Running composer update --ansi in /home/brevetl/lab/github.com/lobre/magento-cloud-docker/_workdir
[Composer\Update]    Time 5.955s
[Composer\Update]  Exit code 2  Time 5.955s

I decided to try to manually cd _workdir and execute the composer update myself but there is a problem of constraints with dependencies.

Problem 1
    - Root composer.json requires magento/ece-tools dev-develop as 2002.1.99, it is satisfiable by magento/ece-tools[dev-develop] from vcs repo (github https://github.com/magento/ece-tools.git) but magento/ece-tools[2002.0-rc30, ..., 2002.1.5] from composer repo (https://repo.magento.com) has higher repository priority. The packages with higher priority do not match your constraint and are therefore not installable. See https://getcomposer.org/repoprio for details and assistance.
  Problem 2
    - Root composer.json requires magento/magento-cloud-docker 1.2.99, it is satisfiable by magento/magento-cloud-docker[1.2.99] from artifact repo (artifacts) but magento/magento-cloud-docker[1.0.0, ..., 1.2.1] from composer repo (https://repo.magento.com) has higher repository priority. The packages with higher priority do not match your constraint and are therefore not installable. See https://getcomposer.org/repoprio for details and assistance.
  Problem 3
    - Root composer.json requires magento/magento-cloud-metapackage >=2.3.5 <2.3.6 -> satisfiable by magento/magento-cloud-metapackage[2.3.5].
    - magento/magento-cloud-metapackage 2.3.5 requires magento/ece-tools ^2002.0.20 -> found magento/ece-tools[2002.0.20, ..., 2002.1.5] but it conflicts with your root composer.json require (dev-develop as 2002.1.99).

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

And now I am stuck. I don't understand why my changes would lead to such errors. Can anybody help?

@BaDos, do you launch functional tests the same as me or is there a more convenient wrapper to execute locally? How did you get the output that you posted above? Did you launch composer from a cli image built from that PR? Because if so, I don't understand how vendor could have been created as root.

BaDos commented 3 years ago

@lobre I will create a manual how to run tests on a local machine when I have time for that.

But you can reproduce it using just magento-cloud template. For example, I use the template 2.3.6

Please follow the steps:

use composer 1.10.*
remove vendor and composer.lock
create the auth.json with needed credential for repo.magento.com and github.com

edit composer.json 3.1. add github repo with your magento-cloud-docker repo:

"repositories": {
    "repo": {
        "type": "composer",
        "url": "https://repo.magento.com"
    },
    "github-docker": {
            "type": "git",
            "url": "https://github.com/<your-magento-cloud-docker-repo>.git"
    }
},

3.2. add your branch to the require section:

"require": {
    "magento/magento-cloud-metapackage": ">=2.3.6 <2.3.7",
    "magento/magento-cloud-docker": "<your-branch> as 1.2.9"
},

composer update

build needed images, for example, I use php 7.3

docker build -t test-php-7.3-cli ./vendor/magento/magento-cloud-docker/images/php/7.3-cli

docker build -t test-php-7.3-fpm ./vendor/magento/magento-cloud-docker/images/php/7.3-fpm

generate docker-compose.yaml
```
./vendor/bin/ece-docker build:compose
```
replace all magento/magento-cloud-docker-php:7.3-fpm-1.2.2 with test-php-7.3-fpm in docker-compose.yaml replace all magento/magento-cloud-docker-php:7.3-cli-1.2.2 with test-php-7.3-cli in docker-compose.yaml
run docker-compose run deploy bash and you can check files permission Also, you can try to run docker-compose run build cloud-build, docker-compose run deploy cloud-deploy

magento-cloud-ft-jenkins-svc commented 3 years ago

Unit & Integration Test Results

:white_check_mark: All unit and integration tests have passed.

Unit Test Output

PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

.....                                                               5 / 5 (100%)

Time: 311 ms, Memory: 12.00 MB

OK (5 tests, 16 assertions)

Generating code coverage report in Clover XML format ... done [786 ms]

Integration Test Output

PHPUnit 8.5.14 by Sebastian Bergmann and contributors.

.............                                                     13 / 13 (100%)

Time: 2.69 seconds, Memory: 30.00 MB

OK (13 tests, 13 assertions)

This comment was generated by Jenkins job magento-cloud-docker/unit build 11.

magento-cloud-ft-jenkins-svc commented 3 years ago

Static Analysis & Code Style Results

:white_check_mark: All static analysis and code style checks have passed.

PHP Codesniffer Output

............................................................ 60 / 89 (67%)
.............................                                89 / 89 (100%)

Time: 4.68 secs; Memory: 10MB

PHP Mess Detector Output


Found 0 violations and 0 errors in 2276ms

[32mNo mess detected[0m

PHPStan Output


 [OK] No errors

This comment was generated by Jenkins job magento-cloud-docker/static build 12.

lobre commented 3 years ago

Hi @BaDos,

Thanks for the guide on how you tested it. I was doing pretty much the same except I tested on one of our MCC repositories instead of directly testing the magento-cloud template.

I have started over with your method and understood the difference. It was because you generate the docker-compose.yml without any parameters while we generate it in developer mode.

./vendor/bin/ece-docker build:compose --mode=developer

This changes a bit the content of the generated docker-compose.yml. When in developer mode, folders such as generated or vendor (the ones you reported as being owned by root above) are mapped as bind mounts. So they show up exactly the same way as on your local filesystem. That's why I had them correctly showing up as my Linux user when I tested with our stack.

However, when you generate the docker-compose.yml in production mode, there are some named volumes that are created and that mount to those generated and vendor folders.

volumes:
  magento-vendor: {  }
  magento-generated: {  }
  magento-var: {  }
  magento-app-etc: {  }
  magento-pub-media: {  }
  magento-pub-static: {  }
  mymagento-magento-db: {  }

  deploy:
    volumes:
      - '.:/app:ro,delegated'
      - 'magento-vendor:/app/vendor:ro,delegated'
      - 'magento-generated:/app/generated:ro,delegated'
      - 'magento-var:/app/var:rw,delegated'
      - 'magento-app-etc:/app/app/etc:rw,delegated'
      - 'magento-pub-media:/app/pub/media:rw,delegated'
      - 'magento-pub-static:/app/pub/static:rw,delegated'
      - '.docker/mnt:/mnt:rw,delegated'

And named volumes in Docker are created by the daemon and end up being owned by root. I am not sure there is any easy way to change that behavior.

The problem that made me create this issue/PR is because developers end up having root files on their local machines (when in developer mode). So I propose that we run fpm and cli as www only when developer mode is activated. Otherwise, in production mode, they will continue to run as root (as before).

That's why I pushed a new commit and used the $MAGENTO_RUN_MODE environment variable to decide whether to execute as root or www in the entrypoints.

Let me know what you think of this solution. Thanks, Loric

magento-cloud-ft-jenkins-svc commented 3 years ago

Functional Acceptance Test Results

:white_check_mark: All functional acceptance tests have passed.

PHP 7.2

:white_check_mark: Elasticsearch72Cest
:white_check_mark: Services72Cest
:white_check_mark: SplitDb72Cest
:white_check_mark: Acceptance72Cest

PHP 7.3

:white_check_mark: Elasticsearch73Cest
:white_check_mark: SplitDb73Cest
:white_check_mark: ServicesCest
:white_check_mark: Acceptance73Cest

PHP 7.4

:white_check_mark: DeveloperCest
:white_check_mark: ElasticsearchCest
:white_check_mark: MailHogCest
:white_check_mark: SplitDbCest
:white_check_mark: AcceptanceCest

This comment was generated by Jenkins job magento-cloud-docker/functional build 14.

BaDos commented 3 years ago

@magento import pr to magento-commerce/magento-cloud-docker

magento-engcom-team commented 3 years ago

@BaDos, an error occurred during the Pull Request import.

flolivaud commented 3 years ago

Hello, Any news here? Is there something blocker about this PR?

oshmyheliuk commented 3 years ago

Hi @flolivaud, We've imported this PR into our internal repo. It will be merged after testing.

IgorVitol commented 3 years ago

@oshmyheliuk @BaDos @lobre

Hi all!

I do not really like the idea of using "gosu" with hardcoded username values in docker-entrypoint script. Also "IF" statement for using different usernames looks like a "hack" (this would add some complexity for devs in the future).

Why not use "USER" instruction in Dockerfile?

USER_NAME=www
USER $USER_NAME

I believe it would be much better to allow "docker-entrypoint" as a single script to be run via "sudo" and keep other script relay on "USER" instruction in Dockerfile (then it would be possible to correctly use "docker run -u" as well when needed)

...
echo "$USER_NAME ALL=(ALL) NOPASSWD:SETENV: /docker_entrypoint.sh" >> /etc/sudoers
...
ENTRYPOINT ["/start.sh"]

Where start.sh:

# Run entry point as root
sudo --preserve-env /docker_entrypoint.sh

# Run other scripts using credentials specified in Dockerfile/passed as docker run arguments.
exec "$@"

lobre commented 3 years ago

Hello @IgorVitol,

Thanks for your interest in that PR. Here are below my thoughts about your proposition.

First, we can note that www is already "hard-coded" into the entrypoint for the update-uid-gid mechanism. So this PR is not about being able to change that www user into something else. It is for permission issues. Whatever the internal user, I want www to be used when generating files that will end up on my local filesystem.

https://github.com/magento/magento-cloud-docker/blob/develop/images/php/cli/docker-entrypoint.sh#L8

So to me, your proposition of not having this user hard-coded is out of the scope of this specific PR. But we can still discuss it.

When you say "keep other script relay on USER instruction", what do you mean exactly? Does it mean scripts should consider the current by using the $USER environment variable (which is normally automatically set)? So something more like:

echo "$USER ALL=(ALL) NOPASSWD:SETENV: /docker_entrypoint.sh" >> /etc/sudoers

With your solution, we also still have the problem raised above with named volumes when in production mode. As long as the docker-compose.yml generation is not changed, we have to use the root user when in production mode.

In my proposition, I kept defaulting to the root user and only switched to www when in developer mode. In your proposition, you are doing the opposite by defaulting to www (or whatever the user is) directly from the Dockerfile instruction (or with -u). That means there should be other changes to revert back to root when run in production mode.

Another point: does your proposition target both fpm and cli? Because it seems it is only applicable for cli. What about fpm? The fpm container should always be run as root and the underlying created pool can be run with a secondary user. That means we would have two different ways of handling users between fpm and cli. I am not sure this is "simpler" for devs in the future.

In the end, I am not sure whether using the sudoers file is less a hack than what I proposed. The only advantage I see is that you could maybe better change the user with docker run -u. But as said earlier, this is a different issue. What would be the reason to change that user? I am not sure I care about what the internal user's name is. What I expect is that created files stay with the same uid as my local filesystem. And www is already user with uid 1000 (which corresponds usually to the local user's uid) so that's fine to me.

Question for maintainers (@oshmyheliuk, @BaDos): what do you think of this other proposition?

To note that I am open to corrections, but I am not sure I personally have spare time at the moment to change the overall design of that PR.

Thanks a lot.

IgorVitol commented 3 years ago

@lobre Hi! Thanks for the reply!

In my proposition, I kept defaulting to the root user and only switched to www when in developer mode.

That's clear. Let's take a look at next example:

# Launch container as www when developer mode is active
# to avoid permission issues with mounted volumes.
if [ "$MAGENTO_RUN_MODE" == "developer" ]; then
    exec gosu www "$@"
else
    exec gosu root "$@"
fi

So, if I would try to run something like this (while in dev mode): docker-compose run --rm -u0 deploy bash

Bash command would be launched as "www" user, even if I would instruct docker to run it as root (ID: 0). That's the issue at least for me. In case of any additional tools required in order to quickly check a few moments - I was able recently to install them directly without requirement to build my own image.

Another point: does your proposition target both fpm and cli? Because it seems it is only applicable for cli. What about fpm? The fpm container should always be run as root and the underlying created pool can be run with a secondary user.

Don't you think that choosing proper username based on CLI/FPM in addition to conditions based on mode (dev/prod) adds real complexity for a developer in future?

Actually both (CLI/FPM) could run via limited user, root is required just for entry-point script for initial configuration (e.g. substitution for config values based on ENV variables). That's why I would suggest to allow entry-point to run as root via sudo/sudoers. In the same time container would be started using limited user (which could be overridden to root via -u0 argument when needed):

# Run as root
sudo --preserve-env /init-configuration.sh

# Run specified command using limited user
exec "$@"

With your solution, we also still have the problem raised above with named volumes when in production mode. As long as the docker-compose.yml generation is not changed, we have to use the root user when in production mode.

That's correct - I have not included the solution in the above example.

In order to avoid confusion here - this has nothing to do with application mode. Magento didn't require root permissions in any mode. The issue here is with additional docker-volumes used while generating the "docker-compose" script for prod mode, in order to emulate all mounts.

All of these mounts should be "chown" once in order to make them work with limited user. So, why we can't do something like this in scope of "init-configuration.sh" ? [ ! -d "${LOG_DIR}" ] && mkdir -p $LOG_DIR && chown -f -R $USER_NAME:$USER_GROUP $MAGENTO_ROOT

Where all of the variables could be defined in Dockerfile:

ENV USER_NAME=www
ENV USER_GROUP=www
ENV MAGENTO_ROOT /app
ENV LOG_DIR $MAGENTO_ROOT/var/log

During first instantiation all of the volumes are clean - here would be no log folder. If folder exists - skip it's creation & avoid chown for each passed command. Otherwise chown everything once. (E.g. change permissions once). If needed - some other condition could be used here.

In result, you would be able to keep all the files using proper user:group ID and keep same user for CLI/FPM in any mode.

CC @shiftedreality @oshmyheliuk

shiftedreality commented 3 years ago

@IgorVitol I really like your approach. The issue that I got is that new files you're sync between Docker and Linux machine are created with the same user ID you have on Linux, and that's where you got issues since www user is in a different group.

Is there some solution for this or I'm missing something?

lobre commented 3 years ago

Hi @IgorVitol,

I also like where this is going. Here are my comments.

In case of any additional tools required in order to quickly check a few moments - I was able recently to install them directly without requirement to build my own image.

I understand this could be a use case, even if I personally never had to do it.

Don't you think that choosing proper username based on CLI/FPM in addition to conditions based on mode (dev/prod) adds real complexity for a developer in future?

I totally do. That's not an amazing design and I agree it could lead to confusion.

Actually both (CLI/FPM) could run via limited user.

That's an interrogation point to me. I have always run FPM as root for the master process. I am not personally sure about the outcome of using a limited user. @IgorVitol, did you already try maybe?

For the volumes part, I don't see any problems with the solution you are proposing.

If maintainers agree and we go in that direction, that will lead to many changes so I guess it will require many tests.

Thanks, Loric

andriyShevtsov commented 3 years ago

@lobre I'm getting error which looks related to this PR:

docker-compose run --rm deploy cloud-deploy                                                                                                                                                                                            
Starting magento-cloud_db_1    ... done
Starting magento-cloud_redis_1         ... done
Starting magento-cloud_elasticsearch_1 ... done
Running "deploy" hook.
[2021-04-07 19:34:10] INFO: Starting scenario(s): scenario/deploy.xml (magento/ece-tools version: 2002.1.4, magento/magento2-base version: 2.4.1-p1)

In StreamHandler.php line 110:

  The stream or file "/app/var/log/cloud.log" could not be opened in append mode: failed to open stream: Permission denied

It happen only in developer mode. May you please check

shiftedreality commented 3 years ago

Hello @lobre, do you need any help with this PR

lobre commented 3 years ago

Hello,

I am not sure what is the status of this PR.

@IgorVitol proposed another design for solving the problem.

What is your point of view on the topic? Should this PR still be considered as is, and merged when leftover problems are fixed?

Unfortunately, I have no free time to spend on this PR at the moment. Someone would have to take over if the aim is to merge soon.

Loric

shiftedreality commented 3 years ago

Thank you @lobre,

I will be working on a different approach and re-use some of your concepts here: https://github.com/magento/magento-cloud-docker/pull/317 If you feel like the current approach should be used instead - please let me know