github-actions-m2's Issues
Improve Configuration With Multiple PHP / Magento Versions
Due to the current structure, testing multiple Magento versions on multiple PHP versions is currently not that nice to configure. We only found the following way to do it:
steps:
- uses: actions/checkout@v2
- name: M2 Integration Tests with Magento 2 Version 2.3.5-p2 (PHP 7.3)
uses: extdn/github-actions-m2/magento-integration-tests/7.3@master
with:
module_name: Vendor_Module
composer_name: vendor/module
ce_version: '2.3.5-p2'
- uses: actions/checkout@v2
- name: M2 Integration Tests with Magento 2 Version 2.3.6-p1 (PHP 7.3)
uses: extdn/github-actions-m2/magento-integration-tests/7.3@master
with:
module_name: Vendor_Module
composer_name: vendor/module
ce_version: '2.3.6-p1'
- uses: actions/checkout@v2
- name: M2 Integration Tests with Magento 2 Version 2.4.1-p1 (PHP 7.3)
uses: extdn/github-actions-m2/magento-integration-tests/7.3@master
with:
module_name: Vendor_Module
composer_name: vendor/module
ce_version: '2.4.1-p1'
- uses: actions/checkout@v2
- name: M2 Integration Tests with Magento 2 Version 2.4.2 (PHP 7.3)
uses: extdn/github-actions-m2/magento-integration-tests/7.3@master
with:
module_name: Vendor_Module
composer_name: vendor/module
ce_version: '2.4.2'
- uses: actions/checkout@v2
- name: M2 Integration Tests with Magento 2 Version 2.4.1-p1 (PHP 7.4)
uses: extdn/github-actions-m2/magento-integration-tests/7.4@master
with:
module_name: Vendor_Module
composer_name: vendor/module
ce_version: '2.4.1-p1'
- uses: actions/checkout@v2
- name: M2 Integration Tests with Magento 2 Version 2.4.2 (PHP 7.4)
uses: extdn/github-actions-m2/magento-integration-tests/7.4@master
with:
module_name: Vendor_Module
composer_name: vendor/module
ce_version: '2.4.2'
It contains a lot of duplications, which is not that nice. I would prefer to use the matrix feature of GitHub Actions. However, it is currently not possible to use a matrix value inside the uses
section of the step configuration (see e.g. https://github.community/t/using-strategy-matrix-values-in-the-specification-of-actions-to-be-used-in-a-workflow/16706). Hence, I think the PHP version should not be referenced in the action name. It should be defined as an option. E.g.:
steps:
- uses: actions/checkout@v2
- name: M2 Integration Tests with Magento 2 Version 2.4.2 (PHP 7.4)
uses: extdn/github-actions-m2/magento-integration-tests@master
with:
module_name: Vendor_Module
composer_name: vendor/module
ce_version: '2.3.5-p2'
php_version: '7.4'
If this was possible, we could simply define a matrix, replace ce_version
and php_version
with the matrix value and we are done.
Check for static type hints and `declare(strict_types=1);`
It would be nice if the PHP_CodeSniffer actions are extended to check for static type hints and whether declare(strict_types=1);
is missing.
e.g. using https://github.com/slevomat/coding-standard
https://github.com/slevomat/coding-standard#slevomatcodingstandardtypehintsdeclarestricttypes-
Use mirror repo for unit tests to avoid need for credentials
The unit test build requires setting secrets.MAGENTO_MARKETPLACE_USERNAME
and secrets.MAGENTO_MARKETPLACE_PASSWORD
.
For myself as the maintainer that is not a problem, but it means I have to ask every contributor to set up the secrets when they open a PR...
I'm just wondering, shouldn't it be possible to execute the build without the credentials, since it also works for the integration test build?
Error: file_put_contents(/m2/app/etc/vendor_path.php): Failed to open stream: No such file or directory
The ExtDN M2 PHPStan workflow returns the below error:
Error: file_put_contents(/m2/app/etc/vendor_path.php): Failed to open stream: No such file or directory
Use the `composer fund` command to find out more!
In PluginManager.php(278) : eval()'d code line 323:
file_put_contents(/m2/app/etc/vendor_path.php): Failed to open stream: No s
uch file or directory
Configuration used:
name: ExtDN M2 PHPStan
on:
push:
branches:
- main
pull_request:
jobs:
phpstan:
name: M2 PHPStan
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: extdn/github-actions-m2/magento-phpstan/8.1@master
with:
composer_name: pronko/workflow-tests-magento-module
Am I missing something in the yaml file or there is an issue with the workflow?
[FEAT] Allow integration tests using EE version
MFTF Support
It would be nice to provide an action for MFTF test execution.
I created this for Bitbucket Pipelines already (see https://www.coderblog.de/running-magento-2-tests-via-bitbucket-pipelines/ although probably a bit outdated), so happy to help with this.
Magento-phpstan Action: Why do we need a composer package for it? Composer 2.0 is not supported!
Hi, thank you for your great works here.
I would like to have 2 questions:
- Why do we need a composer package for it?
- Can you pls update a docker? so it can support Composer 2.0.
Thank you so much!
PHPStan. Add support to change repository url
Hello!
I store my modules as a packages in the private packagist and I faced the problem with PHPStan action: when action is running it tries to download package dependency and falls down with error, cause this package is in the private packagist.
Example of the composer.json
file:
{
"name": "vedor/module-foo-bar",
"type": "magento2-module",
"require": {
"magento/framework": "*",
"vendor/module-from-private-packagist": "*"
},
}
As I can see, the repository
variable is installing in the some places here, here and lastly here.
It would be great to pass the REPOSITORY_URL
and COMPOSER_AUTH
as environment variables same as we are installing them into integration tests action like this:
jobs:
integration-tests:
env:
REPOSITORY_URL: ${{ secrets.REPOSITORY_URL }}
COMPOSER_AUTH: ${{ secrets.COMPOSER_AUTH }}
feat(EQP): allow automated submissions to Magento Marketplace upon release in Github.
I'm not a fan of the current submission process for my OS work to the Magento Marketplace.
The Marketplace UI is fairly tedious, subject to the whims of the modern world of UI design as opposed to "concrete" data-driven design, and less than ideal for a streamlined developer process.
For clarity, to make this point more salient, there are also some minor things that are annoyances that such an action would allow me to automate, but these may be outside the scope of such an action.
Such as:
-
standard-version
, the tool I use to implement semver, doesn't track a version incomposer.json
. This means that the composer.json in my source zip is different than the delivered zip, which is tedious to maintain. -
.gitignore
isn't allowed in Marketplace, resulting in failed source bundle submissions. -
Docs, in theory, could be auto-generated by turning a docs website into a PDF.
It would be lovely if this repo published a Github Action that allowed me to publish updates to my package to the Magento Marketplace automatically as releases are created in Github.
As an MVP, It would be nice to allow for at least only technical updates/technical submissions for an existing package that is assumed to have all the marketing shenanigans already filled out.
To summarize, this would vastly improve my quality of life as an extension developer and would hopefully improve the TTL of critical updates to the marketplace, drastically reducing delays.
Missing Env Variables
As part of #69, we encountered that there are quite some input variables, which are not passed into the Docker container. https://github.com/extdn/github-actions-m2/blob/4091e3ae8e47b4fdaa049a9c64a088c1d06d02f1/magento-integration-tests/entrypoint.sh uses the following inputs, which are not passed into the Docker container here:
github-actions-m2/magento-integration-tests/8.1/action.yml
Lines 44 to 49 in 4091e3a
INPUT_ELASTICSEARCH
INPUT_PHPUNIT_FILE
INPUT_COMPOSER_VERSION
INPUT_REPOSITORY_URL
INPUT_PRE_PROJECT_SCRIPT
INPUT_POST_PROJECT_SCRIPT
INPUT_MAGENTO_PRE_INSTALL_SCRIPT
INPUT_MAGENTO_POST_INSTALL_SCRIPT
Wouldn't all these variables need to be passed as well? Am I missing something?
/cc @jissereitsma
Update extdn/magento-coding-standard-action Docker Images Regularly
Here, we require the latest currently available version of magento/magento-coding-standard
. This will bake this specific version of the coding standard into the Docker image. Before I ran the action to re-build the Docker image manually in https://github.com/extdn/github-actions-m2/actions/runs/5144515585, the Docker image was a few years old. This means that the coding standard used was also a few years old.
Hence, we need to make sure to build the respective docker image regularly.
[Question] Run Magento Coding Standard check on changed files
Hi, folks
I'm currently got an idea to run the extdn/github-actions-m2/magento-coding-standard
on changed list files, example in a pull request.
Any help would be appreciated.
PHPStan "module_source" variable seemingly not used
For my module, I've got it setup so that the tools it'll use are installed in the root directory, and the module is in a src
directory.
I'm trying to run the phpstan action:
In src is a composer.json declaring "swiftotter/correct-module-name"
In . is a composer.json declaring "swiftotter/correct-module-name-toolset"
phpstan:
name: PHPStan
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: extdn/github-actions-m2/magento-phpstan@master
with:
composer_name: swiftotter/correct-module-name
module_source: src/
phpstan_level: 9
The output I'm receiving (with debug logging enabled) is:
2023-02-20T18:54:30.8042647Z ##[group]Run extdn/github-actions-m2/magento-phpstan@master
2023-02-20T18:54:30.8042919Z with:
2023-02-20T18:54:30.8043178Z composer_name: swiftotter/correct-module-name
2023-02-20T18:54:30.8043446Z module_source: src/
2023-02-20T18:54:30.8043657Z phpstan_level: 9
2023-02-20T18:54:30.8043865Z composer_version: 2
2023-02-20T18:54:30.8044060Z ##[endgroup]
2023-02-20T18:54:30.8284118Z ##[command]/usr/bin/docker run --name extdnmagentophpstanactionlatest_3fe127 --label 49859c --workdir /github/workspace --rm -e "INPUT_COMPOSER_NAME" -e "INPUT_MODULE_SOURCE" -e "INPUT_PHPSTAN_LEVEL" -e "INPUT_COMPOSER_VERSION" -e "INPUT_MAGENTO_PRE_INSTALL_SCRIPT" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "RUNNER_DEBUG" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/correct-module-name/correct-module-name":"/github/workspace" extdn/magento-phpstan-action:latest
2023-02-20T18:54:31.1374413Z Setup extension source folder within Magento root
2023-02-20T18:54:31.1459800Z Configure extension source in composer
2023-02-20T18:54:32.2316344Z Pre Install Script:
2023-02-20T18:54:32.2317025Z Run installation
2023-02-20T18:54:33.3598761Z Warning from https://repo.packagist.org: Support for Composer 1 is deprecated and some packages will not be available. You should upgrade to Composer 2. See https://blog.packagist.com/deprecating-composer-1-support/
2023-02-20T18:54:33.3600094Z Info from https://repo.packagist.org: �[37;44m#StandWith�[30;43mUkraine�[0m
2023-02-20T18:54:41.3493418Z
2023-02-20T18:54:41.3547607Z
2023-02-20T18:54:41.3548037Z [InvalidArgumentException]
2023-02-20T18:54:41.3548713Z Could not find package swiftotter/correct-module-name.
2023-02-20T18:54:41.3549026Z
2023-02-20T18:54:41.3549284Z Did you mean this?
2023-02-20T18:54:41.3549663Z swiftotter/correct-module-name-toolset
2023-02-20T18:54:41.3549995Z
2023-02-20T18:54:41.3550137Z
2023-02-20T18:54:41.3551947Z require [--dev] [--prefer-source] [--prefer-dist] [--fixed] [--no-progress] [--no-suggest] [--no-update] [--no-scripts] [--update-no-dev] [--update-with-dependencies] [--update-with-all-dependencies] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [--sort-packages] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--skip-magento-root-plugin] [--use-default-magento-values] [--interactive-magento-conflicts] [--base-magento-edition BASE-MAGENTO-EDITION] [--base-magento-version BASE-MAGENTO-VERSION] [--] [<packages>]...
2023-02-20T18:54:41.3552963Z
2023-02-20T18:54:41.5389034Z ##[debug]Docker Action run completed with exit code 1
2023-02-20T18:54:41.5395696Z ##[debug]Finishing: Run extdn/github-actions-m2/magento-phpstan@master
[Question] Autoload errors with phpstan workflows.
Hello,
I'm getting a lot of "Class X was not found while trying to analyse it - autoloading is probably not configured properly. Learn more at https://phpstan.org/user-guide/autoloading" while using extdn/github-actions-m2/magento-phpstan@master.
I don't have any problems with the coding standard workflow or when I run phpcs locally.
Is this a configuration issue with my workflow, my project or something that needs updating here?
Workflow yml file content:
name: ExtDN M2 PHPStan
on:
push:
branches:
- dev
- main
pull_request:
branches:
- dev
- main
jobs:
phpstan:
name: M2 PHPStan
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: extdn/github-actions-m2/magento-phpstan@master
with:
composer_name: reessolutions/cms-transfer
Monolog 2.7 causes breaking changes that make Integration Tests fail
In my environment, Magento 2.4.4 with PHP 8.1 causes the installation of Monolog 2.7, which again has changed method signatures that are used by the Magento TestFramework to log stuff. This issue is reported at Magento here: magento/magento2#35720
The workaround is to add composer require monolog/monolog:2.6.0
somewhere to the Integration Tests, right before doing a composer install
. I've personally added it to a pre-install script.
Anyone else bumping into this? If so, I might simply add it to the GitHub Action here instead.
Add problem matcher support for PHPMD
In the coding-standard action, support for problem matcher has been added, and when creating a pull request, all the problems found are highlighted when viewing the execution result, as well as when viewing the pull request itself. The found problems that were not affected by the new changes are also displayed.
But when viewing the result of the execution of PHPMD, we can only see the result of the execution by opening the logs. This is inconvenient, since you need to copy the filepath and search for the desired string.
Judging by the PHPMD documentation they have an implemented renderer supported by github
https://phpmd.org/documentation/index.html#renderers
https://phpmd.org/documentation/ci-integration.html#github-actions
Judging by the code, the text
renderer is currently being used, and if it is replaced with "github
, then everything should work automatically.
https://github.com/extdn/github-actions-m2/blob/master/magento-mess-detector/LiveCodePhpmdRunner.php#L62
If it doesn't work, then most likely we need to implement an additional problem matcher to support PHPMD, as it is done for Coding Standard https://github.com/extdn/github-actions-m2/blob/master/magento-coding-standard/problem-matcher.json
Consider repo split and Actions Marketplace listing
To further adoption it would be nice to have the actions listed on the Github Marketplace. Would likely require a separate repo for each.
[BUG] Integration tests fails as a result of recent `composer` breaking changes
Integration tests will currently fail as a result of missing composer plugin allows on composer v2.
Eventually this would result in an error like:
Error: An error occurred trying to start process '/usr/bin/bash' with working directory '/home/runner/work/github-actions-magento2/github-actions-magento2/../magento2/dev/tests/integration'. No such file or directory
with additional warnings like:
laminas/laminas-dependency-plugin contains a Composer plugin which is blocked by your allow-plugins config. You may add it to the list if you consider it safe. See https://getcomposer.org/allow-plugins
You can run "composer config --no-plugins allow-plugins.laminas/laminas-dependency-plugin [true|false]" to enable it (true) or keep it disabled and suppress this warning (false)
dealerdirect/phpcodesniffer-composer-installer contains a Composer plugin which is blocked by your allow-plugins config. You may add it to the list if you consider it safe. See https://getcomposer.org/allow-plugins
You can run "composer config --no-plugins allow-plugins.dealerdirect/phpcodesniffer-composer-installer [true|false]" to enable it (true) or keep it disabled and suppress this warning (false)
magento/composer-root-update-plugin contains a Composer plugin which is blocked by your allow-plugins config. You may add it to the list if you consider it safe. See https://getcomposer.org/allow-plugins
You can run "composer config --no-plugins allow-plugins.magento/composer-root-update-plugin [true|false]" to enable it (true) or keep it disabled and suppress this warning (false)
magento/inventory-composer-installer contains a Composer plugin which is blocked by your allow-plugins config. You may add it to the list if you consider it safe. See https://getcomposer.org/allow-plugins
You can run "composer config --no-plugins allow-plugins.magento/inventory-composer-installer [true|false]" to enable it (true) or keep it disabled and suppress this warning (false)
magento/magento-composer-installer contains a Composer plugin which is blocked by your allow-plugins config. You may add it to the list if you consider it safe. See https://getcomposer.org/allow-plugins
You can run "composer config --no-plugins allow-plugins.magento/magento-composer-installer [true|false]" to enable it (true) or keep it disabled and suppress this warning (false)
See https://github.com/graycoreio/github-actions-magento2/runs/7162488440?check_suite_focus=true
[Question] Static Test action support custom Path
Hi,
I'm currently got some Magento repo with custom code on "app/code".
My goal is to be able to make the Github action Static test execute only on app/code...
By default it's not supported by your nice setup.
I was thinking adding a parameter like there is for the standard, but for the "path to scan" and after if not empty analyze that folder.
Do you think it's the "good way" to go ? thanks
integration tests example with composer cache
The action should be able to use a github action cache mounted into the docker container.
Cannot use PHP 7.4 action for coding standards
I'm trying to use PHP 7.4 for the coding standards action with the following yml file
name: ExtDN M2 Coding Standard
on:
push:
branches:
- master
pull_request:
jobs:
static:
name: M2 Coding Standard
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: extdn/github-actions-m2/magento-coding-standard/7.4@master
Which errors with:
Pull down action image 'extdn/magento-coding-standard-action:7.4-latest'
/usr/bin/docker pull extdn/magento-coding-standard-action:7.4-latest
Error response from daemon: manifest for extdn/magento-coding-standard-action:7.4-latest not found: manifest unknown: manifest unknown
Warning: Docker pull failed with exit code 1, back off 9.014 seconds before retry.
/usr/bin/docker pull extdn/magento-coding-standard-action:7.4-latest
Error response from daemon: manifest for extdn/magento-coding-standard-action:7.4-latest not found: manifest unknown: manifest unknown
Warning: Docker pull failed with exit code 1, back off 8.851 seconds before retry.
/usr/bin/docker pull extdn/magento-coding-standard-action:7.4-latest
Error response from daemon: manifest for extdn/magento-coding-standard-action:7.4-latest not found: manifest unknown: manifest unknown
Error: Docker pull failed with exit code 1
(without /7.4
it works but cannot parse PHP 7.4 syntax obviously)
[BUG]: PHPStan is missing an input for `magento_pre_install_script`
Use composer 2 in the php-7.4 image for faster installation times
Since Magento 2.4 is the only Magento version that is compatible with php 7.4, I think it would be possible to switch the composer version for the php 7.4 image to version 2 without breaking backwards compatibility.
This would speedup the installation of Magento and additional packages significantly, and thus make the action a lot faster.
Please let me know what you think, and if necessary I can make a PR.
Integration tests failing for Magento 2.3
When running integration tests for Magento 2.3 with PHP 7.3, it fails because in commit #87 a change has been introduced that adds a flag during setup which is not available in Magento 2.3.
Run Magento setup: --base-url=http://magento2.test/ --db-host=mysql --db-name=magento2 --db-user=root --db-*** --admin-firstname=John --admin-lastname=Doe [email protected] --admin-user=johndoe --admin-*** --backend-frontname=admin --language=en_US --currency=USD --timezone=Europe/Amsterdam --sales-order-increment-prefix=ORD_ --session-save=db --use-rewrites=1 --search-engine=elasticsearch7
The "--search-engine" option does not exist.
ERROR: Referenced sniff "PHPCompatibility.FunctionUse.RemovedFunctions" does not exist
Hi
We have been using extra/GitHub-actions-m2/Magento-coding-standard/8.1@master for a few months already.
Lately, any action run ends with an error: Referenced sniff "PHPCompatibility.FunctionUse.RemovedFunctions" does not exist.
You can find the action run log here
I would appreciate any help.
Thank you
Itay
Annotation support
It would be really great if they supported Annotations like https://github.com/Mediotype/phpcs-action
Error Running Copy/Paste Detector
Job code:
phpcpd:
name: Magento Copy/Paste Detector
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: extdn/github-actions-m2/magento-copy-paste-detector@master
Error:
Pull down action image 'extdn/magento-copy-paste-detector-action:latest'
/usr/bin/docker pull extdn/magento-copy-paste-detector-action:latest
Error response from daemon: pull access denied for extdn/magento-copy-paste-detector-action, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
Warning: Docker pull failed with exit code 1, back off 9.922 seconds before retry.
/usr/bin/docker pull extdn/magento-copy-paste-detector-action:latest
Error response from daemon: pull access denied for extdn/magento-copy-paste-detector-action, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
Warning: Docker pull failed with exit code 1, back off 9.411 seconds before retry.
/usr/bin/docker pull extdn/magento-copy-paste-detector-action:latest
Error response from daemon: pull access denied for extdn/magento-copy-paste-detector-action, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
Error: Docker pull failed with exit code 1
Feat: Support PHP 8.1 Actions
Unable to parse fixtures error on Magento 2.4.5
Running github action on Magento 2.4.5 fails and shows the following error:
Unable to parse fixtures
#0 /tmp/m2/local-source/__extdn_github-actions-m2_7/Test/Integration/Console/Command/Tax/Rates/EditCommandTest.php(52): CustomGento\CliTaxEditor\Test\Integration\Console\Command\Tax\Rates\EditCommandTest->testExecuteWithoutTitles()
Caused By: Call to undefined method ReflectionMethod::getAttributes()
#0 /tmp/m2/dev/tests/integration/framework/Magento/TestFramework/Annotation/Parser/Composite.php(47): Magento\TestFramework\Fixture\Parser\IndexerDimensionMode->parse(Object(CustomGento\CliTaxEditor\Test\Integration\Console\Command\Tax\Rates\EditCommandTest), 'method')
#1 /tmp/m2/dev/tests/integration/framework/Magento/TestFramework/Annotation/IndexerDimensionMode.php(165): Magento\TestFramework\Annotation\Parser\Composite->parse(Object(CustomGento\CliTaxEditor\Test\Integration\Console\Command\Tax\Rates\EditCommandTest), 'method')
#2 /tmp/m2/dev/tests/integration/framework/Magento/TestFramework/Annotation/IndexerDimensionMode.php(105): Magento\TestFramework\Annotation\IndexerDimensionMode->parse(Object(CustomGento\CliTaxEditor\Test\Integration\Console\Command\Tax\Rates\EditCommandTest))
#3 [internal function]: Magento\TestFramework\Annotation\IndexerDimensionMode->startTest(Object(CustomGento\CliTaxEditor\Test\Integration\Console\Command\Tax\Rates\EditCommandTest))
#4 /tmp/m2/dev/tests/integration/framework/Magento/TestFramework/EventManager.php(49): call_user_func_array(Array, Array)
#5 /tmp/m2/dev/tests/integration/framework/Magento/TestFramework/Event/PhpUnit.php(127): Magento\TestFramework\EventManager->fireEvent('startTest', Array)
#6 /tmp/m2/vendor/phpunit/phpunit/src/Framework/TestResult.php(438): Magento\TestFramework\Event\PhpUnit->startTest(Object(CustomGento\CliTaxEditor\Test\Integration\Console\Command\Tax\Rates\EditCommandTest))
#7 /tmp/m2/vendor/phpunit/phpunit/src/Framework/TestResult.php(661): PHPUnit\Framework\TestResult->startTest(Object(CustomGento\CliTaxEditor\Test\Integration\Console\Command\Tax\Rates\EditCommandTest))
#8 /tmp/m2/vendor/phpunit/phpunit/src/Framework/TestCase.php(903): PHPUnit\Framework\TestResult->run(Object(CustomGento\CliTaxEditor\Test\Integration\Console\Command\Tax\Rates\EditCommandTest))
#9 /tmp/m2/vendor/phpunit/phpunit/src/Framework/TestSuite.php(670): PHPUnit\Framework\TestCase->run(Object(PHPUnit\Framework\TestResult))
#10 /tmp/m2/vendor/phpunit/phpunit/src/Framework/TestSuite.php(670): PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
#11 /tmp/m2/vendor/phpunit/phpunit/src/Framework/TestSuite.php(670): PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
#12 /tmp/m2/vendor/phpunit/phpunit/src/TextUI/TestRunner.php(673): PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
#13 /tmp/m2/vendor/phpunit/phpunit/src/TextUI/Command.php(143): PHPUnit\TextUI\TestRunner->run(Object(PHPUnit\Framework\TestSuite), Array, Array, true)
#14 /tmp/m2/vendor/phpunit/phpunit/src/TextUI/Command.php(96): PHPUnit\TextUI\Command->run(Array, true)
#15 phpvfscomposer:///tmp/m2/vendor/phpunit/phpunit/phpunit(97): PHPUnit\TextUI\Command::main()
#16 /tmp/m2/vendor/bin/phpunit(118): include('phpvfscomposer:...')
#17 {main}
The whole log can be seen here: https://github.com/customgento/module-cli-tax-editor-m2/runs/7898194786?check_suite_focus=true
One thing i noticed is that the phpunit.xml
file for the actions is a bit outdated compared to the phpunit.xml
file in Magento 2.4.5
Strangely enough, the issue can't be reproduced locally (even when https://github.com/extdn/github-actions-m2/blob/master/magento-integration-tests/docker-files/phpunit.xml is added to the local instance)
Add PHP 8.1 support for PHPStan
Add PHP version infrastructure similar to the approach with unit tests and integration tests. Add PHP 8.1, following from that. Make sure that the workflows in this repository are also picking up on new commits and/or PRs, so that Docker images are built automatically. Ask @sprankhub to do the work.
Newer PHPUnit versions don't allow for non-existing directories in testsuites
In the phpunit.xml
file shipped with the ExtDN Integration Tests, there are multiple different directories mentioned for the testsuite. In my personal case, the first folder matches my tests. The other ones are simply included "just in case".
<testsuites>
<testsuite name="IntegrationTests">
<directory suffix="Test.php">../../../vendor/%COMPOSER_NAME%/Test/Integration</directory>
<directory suffix="Test.php">../../../vendor/%COMPOSER_NAME%/tests/Integration</directory>
<directory suffix="Test.php">../../../vendor/%COMPOSER_NAME%/tests/integration</directory>
<directory suffix="Test.php">../../../vendor/%COMPOSER_NAME%/src/Test/Integration</directory>
<directory suffix="Test.php">../../../vendor/%COMPOSER_NAME%/src/tests/Integration</directory>
<directory suffix="Test.php">../../../vendor/%COMPOSER_NAME%/src/tests/integration</directory>
</testsuite>
</testsuites>
Unfortunately, newer versions of PHPUnit (todo: which ones? well, newer ones, at least with Magento 2.4.4 under PHP 8.1) give a failure when one of these folders is missing. My solution is now to use the PHPUNIT_FILE
input or env variables to bring in a new PHUnit file where I remove all non-relevant files. But this is getting annoying.
One possible (breaking) fix would be to let go of the testsuites entirely, simply passing the sources to PHPUnit as an argument. In entrypoint.sh
this would change the following last line:
cd $MAGENTO_ROOT/dev/tests/integration && ../../../vendor/bin/phpunit -c phpunit.xml
to:
cd $MAGENTO_ROOT/dev/tests/integration && ../../../vendor/bin/phpunit -c phpunit.xml $GITHUB_WORKSPACE
Another fix would be to remove all lines except the top one. but this would break at least the workflow of @fooman .
Yet another fix would be to make it simpler to override the PHPUnit file. Instead of requiring the PHPUnit variable to be defined in your workflow, we could simply check for a relevant file in the .github/workflows/
folder. But that sounds a bit too magical for me.
PHP 8.2 Support
Since Magento 2.4.6 supports PHP 8.2, we should add support for this as well.
Change build dir to be under GITHUB_WORKSPACE
Additional action steps are unable to access the Magento build that is local to the /tmp/m2 directory.
Proposed solution:
- Check out the module source to a subdirectory of GITHUB_WORKSPACE, e.g.
$GITHUB_WORKSPACE/source
. - Change the build directory to
$GITHUB_WORKSPACE/build
.
This already seems to have been intended at one point of time according to the otherwise unused $MODULE_SOURCE
variable when the local-source is set up.
This would allow adding additional steps that can reference the existing build.
How can I run M2 PHPStan on specific branch not on composer package
Github.com contains invalid characters caused by old composer docker images
When running job with COMPOSER_AUTH variable this form:
{
"http-basic": {
"repo.magento.com": {
"username": "XXX",
"password": "XXX"
}
},
"github-oauth": {
"github.com": "XXXX"
}
Pipeline throws:
Your github oauth token for github.com contains invalid characters: "***"
I believe it would be solved by rebuilding all composer based images.
Reference: https://twitter.com/seldaek/status/1395375090603286534
https://nono.ma/github-oauth-token-for-github-com-contains-invalid-characters-on-composer-install
As a hacky workaround you have to put github credentials in http basic.
Add support for new Variables
Add support for ${{ vars.FOOBAR }}
. See https://github.blog/changelog/2023-01-10-github-actions-support-for-configuration-variables-in-workflows/
Add php copy paste detector action
it would be awesome to add phpcpd
Fix issue with memory helper in early 2.3
There are a couple of M2 core issues
2.3.0 is broken due to
In Filesystem.php line 156:
[Magento\Framework\Exception\LocalizedException]
The XML in file "/tmp/m2/vendor/magento/module-inventory-catalog/etc/commun
ication.xml" is invalid:
Element 'topic', attribute 'is_synchronous': The attribute 'is_synchronous'
is not allowed.
Line: 9
Element 'topic', attribute 'is_synchronous': The attribute 'is_synchronous'
is not allowed.
Line: 12
Element 'topic', attribute 'is_synchronous': The attribute 'is_synchronous'
is not allowed.
Line: 15
Element 'topic', attribute 'is_synchronous': The attribute 'is_synchronous'
is not allowed.
Line: 18
Element 'topic', attribute 'is_synchronous': The attribute 'is_synchronous'
is not allowed.
Line: 21
Verify the XML and try again.
see https://github.com/extdn/extension-dashboard-m2/runs/1312019553?check_suite_focus=true
2.3.1 - 2.3.3
broken due to
OK (4 tests, 5 assertions)
Fatal error: Uncaught PHPUnit\Framework\Exception: Notice: Undefined variable: e in /tmp/m2/dev/tests/integration/framework/Magento/TestFramework/Helper/Memory.php:52.
/tmp/m2/dev/tests/integration/framework/bootstrap.php:134
/tmp/m2/dev/tests/integration/framework/Magento/TestFramework/Helper/Memory.php:52
/tmp/m2/dev/tests/integration/framework/Magento/TestFramework/MemoryLimit.php:127
/tmp/m2/dev/tests/integration/framework/Magento/TestFramework/MemoryLimit.php:59
/tmp/m2/dev/tests/integration/framework/Magento/TestFramework/Bootstrap/Memory.php:50
thrown in /tmp/m2/dev/tests/integration/framework/bootstrap.php on line 134
https://github.com/extdn/extension-dashboard-m2/runs/1312039797?check_suite_focus=true
see https://github.com/extdn/extension-dashboard-m2/runs/1312423133?check_suite_focus=true
[BUG] Magento 2 Tests Integration tests fail unless the key USE_OVERRIDE_CONFIG is set to enabled in `phpunit.xml`
See the phpunit.xml.dist
To be perfectly honest, this configuration setting is beyond me. I spent an hour with @MateusDadalto (after he spent a whole day) trying to understand this configuration settings purpose is.
In short, it looks like during a test run in dev/tests/integration
in v2.4.3, Magento installs some modules into app/code/Magento
.
After test cleanup
- These extraneous test module files are deleted
- Magento also triggers a
session_close
3session_close
triggers a native Magento 2 plugin to retrieve a value fromScopeConfigInterface
getValue
triggers a config merge- Config merge does a
fopen
on a now deleted fileapp/code/Magento/TestModuleFakePaymentMethod/etc/config.xml
Fatal error: Uncaught Magento\Framework\Exception\FileSystemException: The "/tmp/m2/app/code/Magento/TestModuleFakePaymentMethod/etc/config.xml" file doesn't exist. in /tmp/m2/vendor/magento/framework/Filesystem/File/Read.php:76
Stack trace:
#0 /tmp/m2/vendor/magento/framework/Filesystem/File/Read.php(62): Magento\Framework\Filesystem\File\Read->assertValid()
#1 /tmp/m2/vendor/magento/framework/Filesystem/File/Read.php(52): Magento\Framework\Filesystem\File\Read->open()
#2 /tmp/m2/vendor/magento/framework/Filesystem/File/ReadFactory.php(45): Magento\Framework\Filesystem\File\Read->__construct('/tmp/m2/app/cod...', Object(Magento\Framework\Filesystem\Driver\File))
#3 /tmp/m2/vendor/magento/framework/Config/FileIterator.php(70): Magento\Framework\Filesystem\File\ReadFactory->create('/tmp/m2/app/cod...', 'file')
#4 /tmp/m2/vendor/magento/framework/App/Config/Initial/Reader.php(93): Magento\Framework\Config\FileIterator->current()
#5 /tmp/m2/vendor/magento/module-config/App/Config/Source/ModularConfigSource.php(42): Magento\F in /tmp/m2/vendor/magento/framework/Filesystem/File/Read.php on line 76
Regardless, we need the USE_OVERRIDE_CONFIG
in the phpunit.xml because of reasons.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.