extdn / github-actions-m2 Goto Github PK

View Code? Open in Web Editor NEW

132.0 132.0 46.0 1.36 MB

Dockerfile 5.50% Shell 26.91% JavaScript 8.46% PHP 23.77% Roff 35.36%

github-actions-m2's People

Contributors

Stargazers

Watchers

Forkers

hiepnt93 jissereitsma river0825 julienanquetil tiagosampaio hieptransutunam vinai aredubya coresh shikhamis11 bavaan-platform vinodsowdagar multisafepay imi-digital slackerzz eclipse-digital deniscsz dna-matt trunglv dominicwatts df2k2 damienwebdev govindasharma iamdylanngo practice-code fredden apostatedevops borisovskip aonach magepow lucianturiacarnia pleminh rbouma waleedbasit sprankhub norgeindian genecommerce tuyennn start-mage davidduong90 iranimij skullsneeze webgrip

github-actions-m2's Issues

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.

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

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

    
           env: 
        
             MODULE_NAME: ${{ inputs.module_name }} 
        
             COMPOSER_NAME: ${{ inputs.composer_name }} 
        
             MAGENTO_VERSION: ${{ inputs.ce_version }} 
        
             PROJECT_NAME: ${{ inputs.project_name }} 
        
             COMPOSER_MEMORY_LIMIT: -1

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

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.

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

[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.

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/

[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.

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.

integration tests example with composer cache

The action should be able to use a github action cache mounted into the docker container.

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!

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

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.

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 in composer.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.

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.

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.

[FEAT] Allow integration tests using EE version

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)

Update extdn/magento-coding-standard-action Docker Images Regularly

github-actions-m2/magento-coding-standard/Dockerfile:8.1

Line 5 in b2e359e

RUN /usr/local/bin/composer global require magento/magento-coding-standard:*

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.

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] 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

My fix is here

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.

[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
3 session_close triggers a native Magento 2 plugin to retrieve a value from ScopeConfigInterface
getValue triggers a config merge
Config merge does a fopen on a now deleted file app/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.

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.

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-

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?

PHP 8.2 Support

Since Magento 2.4.6 supports PHP 8.2, we should add support for this as well.

How can I run M2 PHPStan on specific branch not on composer package

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 }}

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?

Feat: Support PHP 8.1 Actions

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

Add php copy paste detector action

it would be awesome to add phpcpd

[BUG]: PHPStan is missing an input for `magento_pre_install_script`

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.

Annotation support

It would be really great if they supported Annotations like https://github.com/Mediotype/phpcs-action

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] 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

	env:
	MODULE_NAME: ${{ inputs.module_name }}
	COMPOSER_NAME: ${{ inputs.composer_name }}
	MAGENTO_VERSION: ${{ inputs.ce_version }}
	PROJECT_NAME: ${{ inputs.project_name }}
	COMPOSER_MEMORY_LIMIT: -1