mage-os / github-actions

Mage-OS GitHub Actions for the distribution repositories.

Magento 2 GitHub Actions

Opinionated Github Actions and Workflows to make building, testing, and maintaining Magento 2 Modules easier.

• README if you are new to Github Actions.
• What is a workflow?
• What is an action?

Workflows

Workflow Name	Description
Integration Test	A Github Workflow that runs the Integration Tests of a Magento Package

Actions

Action Name	Description
Unit Test	A Github Action that runs the Unit Tests a Magento Package
Fix Magento Install	A Github Action that fixes Magento before composer install
Cache Magento	A Github Action that creates a composer cache for a Magento extension or store.
Setup Magento	A Github Action that sets up Magento before composer install for an extension or store.
Get Magento Version	A Github Action that computes the installed Magento version.
Installation Test	A Github Action that tests the installability of a Magento Package
Semver Compare	A Github Action that semantically compares two versions
Supported Version	A Github Action that computes the currently supported Github Actions Matrix for Magento 2

github-actions's Issues

[BUG] Various automatic changelog generation and release generation aspects are not working

🐛 Bug report

Current Behavior

Various commits do not follow conventions.

Expected Behavior

All commits follow conventions.

Minimal reproduction of the problem with instructions

• e12e899 - merged by @sprankhub
• dcd92b1 - merged by @sprankhub
• 76fcd70 - merged by @Vinai

What is the motivation / use case for changing the behavior?

We auto-generate the changelog and versioned create a PR for automatic releases, making this project much easier to use.

To add to this - mage-os/terraform#75 is also preventing the bot from creating PRs

[RFC] Removal of publicly-facing workflows

💡 Feature request

Feature Name

No public workflows.

The Desired Behavior

I would like for there to be no workflows available in the public API of this repo.

Your Use Case

Previously, we exposed an integration workflow that others could use to run integration tests.

This is rather brittle and is too inflexible for more complex use-cases like #14 or supporting Opensearch or any search driver/database service/caching service, etc.

The reason we had workflows in the first place was so that I could encapsulate the services logic that the workflows use. It turns out that we don't need to do this at all.

Instead, I would like to expose an action with a usage interface like:

jobs:
    compute_env:
      runs-on: ubuntu-latest
      outputs:
        matrix: ${{ steps.supported-services.outputs.services }}
      steps:
        - uses: actions/checkout@v3

        - uses: mage-os/github-actions/supported-version@main
           id: supported-version

        - uses: mage-os/github-actions/supported-services@main
           id: supported-services
           with:
               configurations: '?'
    
    test
        needs: [compute_matrix]
        services: ${{ fromJson(needs.compute_env.outputs.services ) }}
        steps:
           - run: echo "Run tests..."
             shell: bash

I would like some feedback on what the API of such an action could be.

My current struggle is to find an input that allows controlled flexibility.

configuration - minimal, common, full, commerce-cloud, custom

Prior Work

#14
#139

[FEAT] An action that builds a fpm and cli docker image

💡 Feature request

Feature Name

• docker-build

The Desired Behavior

Build a Magento codebase for docker onto a fpm and cli image. There's documentation of this here: https://docs.mappia.io/containerizing.html

Your Use Case

• As a developer, I would like to have a pre-built action that attempts to build a docker image of a Magento store.
• I would like lower the barrier to entry to Docker + Magento as well as improve the on-ramp to https://www.mappia.io/

Copied from graycoreio/github-actions-magento2#66

[DOCS] `cache-magento` docs have an extraneous input

📄 Documentation Request

What were you doing?

I was trying to use cache-magento and I saw:

Unexpected input(s) 'magento_directory', valid inputs are ['composer_cache_key', 'mode']

In my logs.

Expected behavior

I expected to use cache-magento to add composer caching to my pipeline.

Existing Documentation

https://github.com/mage-os/github-actions/blob/main/cache-magento/README.md

[FEAT] Create an action that works with the MageOS nightlies to determine whats going to break between your current Magento version and the next.

💡 Feature request

Feature Name

Nightly Compatibility Report

The Desired Behavior

I would love to have a PR that computes the https://github.com/AmpersandHQ/ampersand-magento2-upgrade-patch-helper and then submits an issue that contains the output as a report so that we know what's to come.

Your Use Case

• As a developer, I would love to be informed of what's upcoming in the next Magento release.
• As a business owner, I would love to be able to predict how much an upgrade will cost.

Prior Work

https://github.com/AmpersandHQ/ampersand-magento2-upgrade-patch-helper

cc: @convenient

Copied from graycoreio/github-actions-magento2#65

[FEAT] Support Static Tests

💡 Feature request

Feature Name

static-test

The Desired Behavior

As a developer, I want to run the static tests of Magento.

Your Use Case

Prior Work

graycoreio/github-actions-magento2#90

cc: @DavidLambauer

[CHORE] Fix all `::set-output` deprecations

chore

In the project, we use a lot of actions. These actions are actually dependencies of the project and depend on Github's features and the peripheral ecosystem. We need to keep these maintained.

This issue tracks fixing the ::set-output deprecations.

[FEAT] Create an action that builds a alpine dockerfile of a magento store.

💡 Feature request

Feature Name

Magento 2 Docker Build

The Desired Behavior

As a developer, I want to use Docker containers with Magento 2. Specifically, I want a build that will generate a CLI container and a FPM container.

Your Use Case

Quickly running Magento 2 in Kubernetes.

Prior Work

https://github.com/damienwebdev/mageos-docker contains this code.

Copied from graycoreio/github-actions-magento2#80

[FEAT] As a developer, I want to know if my Magento VCS `config.php` is in sync with what would be deployed.

💡 Feature request

Feature Name

check-config

The Desired Behavior

I would like to be able to use a Github action called check-config which verifies (without having an associated database connection) that my local config.php is in sync with what would result from setup:upgrade.

Your Use Case

I very often find that developers forget to commit their updates to config.php. If you're doing di:compile ahead of time in docker for example, then your build output will not be what you expect if your config.php isn't up to date.

cc: @vitaliy-golomoziy

[CHORE] September 2023 Maintenance

chore

We need to keep this project well-updated. We have dependencies and those dependencies change.

We need to:

• Update all dependencies from package.json
• Update all dependencies from our actions.

[OTHER] Update Github Repo Search Tags

[FEAT] Add support for cs2pr to magento2-coding-standard phpcs Github Actions

💡 Feature request

Feature Name

Coding Standard

The Desired Behavior

@ihor-sviziev requested that we leverage cs2pr to add info the Github Action

graycoreio/github-actions-magento2#27 (comment)

Your Use Case

Nicer code review :)

Prior Work

graycoreio/github-actions-magento2#27 (comment)

Copied from graycoreio/github-actions-magento2#71

cc: @gowrizrh

[FEAT] As a developer, I want to be able to test upcoming versions of Magento on supported-version in a pseudo-known state.

💡 Feature request

Feature Name

When testing the MageOS repo, it would be nice to know what versions will be coming soon so that other kinds of tests can be run and verified on launch day. This will make day-of-release mechanisms much more stable.

The Desired Behavior

Add release-date to supported-version entries and add a new kind called coming-soon.

Your Use Case

As @Vinai, I would like to know the dependencies of upcoming (but unreleased) Magento versions will be coming soon so that other kinds of tests can be run and verified on launch day against the preview mirror.

Prior Work

This came from a discussion of the v2.4.6 release between @Vinai and myself.

Copied from graycoreio/github-actions-magento2#164

[FEAT] Replace Token in Release Please

💡 Feature request

Feature Name

Release please automation!

The Desired Behavior

I don't want to manually create releases.

This needs to be the CI Bot token https://github.com/mage-os/github-actions/blob/main/.github/workflows/release-please.yml#L14

[FEAT] As a developer, I want to see these actions listed on the Github Marketplace.

💡 Feature request

Feature Name

Github-Actions Monorepo splitter.

The Desired Behavior

It would be great if we could list these actions on the marketplace for better visibility.

@Tjitse-E was the original one to point this out, but the common pattern for actions is to put them in their own repo.

Luckily enough, since this is a git repo, doing sub-repo splits and tagging is actually quite easy.

I have an action that already does this:

name: "Publish Subtree"
author: "Graycore"
description: "A Github Action that publishes a subdirectory of a monorepo to another repo"

inputs:
  targetRepo:
    description: repository to sync the files to
    required: true
  sourceDir:
    description: sub-directory that will be the source of the repository
    required: true
  token:
    description: Github Token
    required: true
  syncBranch:
    default: sync-branch
    description: temporary branch that will be used for syncing
    required: false

runs:
  using: composite
  steps:
    # Add the target repository as a remote and fetch its branches
    - name: Add target repo and fetch branches
      run: |
        git remote add target https://oauth2:${{ inputs.token }}@${{ inputs.targetRepo }}
        git fetch target
      shell: bash
    # Sync the subdirectory using git subtree
    - name: Create subtree branch
      run: |
        git subtree split --prefix=${{ inputs.sourceDir }} -b ${{ inputs.syncBranch }}
      shell: bash
    # Push the changes to the target repository
    - name: Push changes to target repo
      run: |
        git push target ${{ inputs.syncBranch }}:main
      shell: bash
    # Create tag and push to target repo if triggered by tag event
    - name: Create tag
      if: github.ref_type == 'tag'
      shell: bash
      run: |
        git checkout ${{ inputs.syncBranch }}
        git config --global user.email "[email protected]"
        git config --global user.name "Beep Boop"
        git tag -a subtreetag -m ${{ github.ref_name }}
        git push target subtreetag:${{ github.ref_name }}

But I haven't published it anywhere public. Feel free to use it, I'm stating it as MIT-licensed.

Your Use Case

As a developer, I want to see these actions listed on the Github Marketplace.

[FEAT] User-friendly job names for jobs following `supported-versions`

💡 Feature request

Feature Name

Improve Job Naming for resulting tasks from supported-version

The Desired Behavior

It would be nice to have a friendly name like "v2.4.4-p2orMage-2.4.4-p2` instead of the long name.

Your Use Case

@DavidLambauer was writing static tests and ran into some annoying UI problems

Prior Work

mage-os/mageos-magento2#4 (comment)

Copied from graycoreio/github-actions-magento2#96

[FEAT] Magento Coding Standards / PHP Compatibility tests

💡 Feature request

Feature Name

Run Magento Coding Standards on top of my module(s)

The Desired Behavior

I'd like to have the ability to run the Magento Coding Standards static test for my module from the module' or from the project's repository.
In addition to that, I'd like to select the Coding Standard version.

Also, I would like to have the ability to run PHP compatibility tests.

https://github.com/magento/magento-coding-standard
https://github.com/PHPCompatibility/PHPCompatibility

Note: here are the examples:
https://github.com/extdn/github-actions-m2/tree/master/magento-coding-standard
https://github.com/extdn/github-actions-m2/tree/master/magento-copy-paste-detector
https://github.com/extdn/github-actions-m2/tree/master/magento-mess-detector
https://github.com/extdn/github-actions-m2/tree/master/magento-phpstan
https://github.com/extdn/github-actions-m2/tree/master/php-compatibility

They are based on docker and do not support configuring the standard coding version, for instance.

TODO:

• Run PHPCS on top of magento-coding-standard
• Run PHPCS for PHP compatibility
• Run PhpStan
• Run PHPMD
• Run Copy-Paste detector

Your Use Case

Prior Work

Environment

Magento version: X.Y.Z 
PHP Version version: X.Y.Z 


Others:

Copied from graycoreio/github-actions-magento2#27

cc: @ihor-sviziev

[FEAT] `fix-magento-install` should use the new `get-composer-version` action

💡 Feature request

The Desired Behavior

I'd imagine that we should dog-food our actions.

• https://github.com/mage-os/github-actions/blob/main/fix-magento-install/action.yml

Should use

• https://github.com/mage-os/github-actions/tree/main/get-composer-version

Your Use Case

Reuse.

[FEAT] `get-composer-version` action

💡 Feature request

Feature Name

get-composer-version

The Desired Behavior

I often find myself in need of knowing the current composer version. Unfortunately, composer's output is:

damien@DESKTOP-N7ABP4H:/mnt/c/Windows/system32$ composer --version --help
Composer version 2.2.18 2022-08-20 11:33:38

I only want 2.2.18

Your Use Case

As a user, I want to get the currently installed composer version number.

cc: @vitaliy-golomoziy

[FEAT] Automatically build `supported-version` and commit it if someone forgets to do so.

💡 Feature request

Feature Name

Automatic supported-versions builds.

The Desired Behavior

As a developer, I would like to be able to forget to build supported-version and not break everything.

I essentially would like to be forced to run cd supported-version && npm run build on commit if I change supported-version. This could also be done by the CI bot.

Your Use Case

@Vinai and I often forget to run npm run build when working on supported-version. As a result, the output drifts from the source which is very confusing.

[FEAT] Pin internal action usages to the currently released version as opposed to `main`.

💡 Feature request

Feature Name

Internal version consistency

The Desired Behavior

When I use https://github.com/mage-os/github-actions/blob/main/fix-magento-install/action.yml#L12 It uses mage-os/github-actions/get-magento-version@main. This should instead be mage-os/github-actions/[email protected] (or whatever the current version is). Then, when we do a PR like #125 it should automatically bump this version.

Your Use Case

Developers really shouldn't be relying on main. It's not supposed to be that stable. We should document the currently leading version, allowing main to be a little less stable.

Prior Work

Release please supports with in .release-please-config.json with extra-files

 {
  ...
  "extra-files": [
    "path/to/file"
  ],
   ...
 }

You simply have to add # x-release-please-version on the line with the version in it.

[FEAT] Run integration tests w/o Rabbitmq

💡 Feature request

Feature Name

The Desired Behavior

I never saw integration tests that depend on RabbitMQ. Since there is a way to install Magento w/o it - I think it's a good idea to speed up the integration test.

Currently, I'm not using these actions because of this.
here is my config preparation for integration tests:

      - name: Replace Configuration Settings for env
        working-directory: ./magento2/dev/tests/integration/etc
        run: |
          cat install-config-mysql.php.dist \
            | sed "s/'db-host' => 'localhost'/'db-host' => '127.0.0.1'/" \
            | sed "s/'db-user' => 'root'/'db-user' => 'user'/" \
            | sed "s/'db-password' => '123123q'/'db-password' => 'password'/" \
            | sed "s/'elasticsearch-host' => 'localhost'/'elasticsearch-host' => '127.0.0.1'/" \
            | sed '/amqp/d' > install-config-mysql.php

Your Use Case

Prior Work

Environment

Magento version: X.Y.Z 
PHP Version version: X.Y.Z 


Others:

cc: @ihor-sviziev

Copied from graycoreio/github-actions-magento2#64

[BUG] Replace Graycore References With Mage-OS

🐛 Bug report

Current Behavior

There are still quite some references to the "old" graycore repository.

Expected Behavior

There are no references to the "old" graycore repository. Only the mage-os repository is referenced.

Minimal reproduction of the problem with instructions

grep -ri 'graycore'

What is the motivation / use case for changing the behavior?

I think it is cleaner if we only use Mage-OS from now on.

Environment

Magento version: *
PHP Version version: *


Others: n/a

[FEAT] Cypress Tests

💡 Feature request

Feature Name

Cypress-Test-Action

The Desired Behavior

Automated E2E tests for out of box store validation.

Your Use Case

As a user, if I'm testing an extension, I may want to do E2E tests to validate that I didn't break anything.

Prior Work

https://github.com/elgentos/magento2-cypress-testing-suite

Copied from graycoreio/github-actions-magento2#49

[FEAT] automatic class documentation header

To enhance the documentation of the core, I would love to see an action that runs on every pull request and adds a small three-line documentation snippet to every class that was touched in that specific pull request. The contributor and the reviewer are then supposed to go the extra mile, and also review these three lines of documentation.

The content of these three lines should be a description about the purpose of the class.

This would greatly improve the documentation of the core code overtime, and it's just a little overhead for every contributor.

Technically speaking, this action Would connect to a GPT API, send the class content as part of the prompt and receive the formatted three lines of documentation. The action can further validate The format and syntax.

This approach follows the Boy Scout principal, and is very defensive in terms of actual changes. We could also just write the comments with chat GPT as we did in a similar fashion for the developer documentation.

[FEAT] Use `composer.lock` to find installed Magento version in `store` mode of `get-magento-version`

💡 Feature request

Feature Name

Get Locked versions

The Desired Behavior

In get-magento-version we attempt to compute the version of Magento installed. Right now, we attempt to find the version in the composer.json. We should instead prefer the lock file.

Your Use Case

#126

[DOCS] Duplicate CODEOWNERS

https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#codeowners-file-location

With the terraform CODEOWNERS in:

1. https://github.com/mage-os/github-actions/blob/main/CODEOWNERS
2. https://github.com/mage-os/github-actions/blob/main/.github/CODEOWNERS

We have competing CODEOWNERS

[FEAT] Add Support for v2.3.7-p3 and v2.3.7-p4 running on Ubuntu-20.04.

💡 Feature request

Feature Name

Currently, v2.3.7-p3 and v2.3.7-p4 run on Ubuntu-18.04. This is no longer supported.

The Desired Behavior

As a MageOS internal developer, I need to be able to integration test the v2.3.7-p3 and v2.3.7-p4 releases if we make a change to the release generator.

Your Use Case

We want to be able to build and test v2.3.7-p3 and v2.3.7-p4 for users stuck on older releases.

[FEAT] Add support for `magento/magento-cloud-metapackage` in `get-magento-version`

💡 Feature request

Feature Name

I was trying to use these actions with a Magento Cloud project. Unfortunately, we don't compute get-magento-version that key for stores.

The Desired Behavior

I would like to be able to drop an action like the following into my Github actions and retrieve the correct Magento version.

steps:
- uses: mage-os/github-actions/get-magento-version@main
  id: get-magento-version
      with:
          working-directory: ${{ secrets.GITHUB_WORKSPACE }}

Your Use Case

As a developer, I would like to be able to compute the currently installed Magento version for Magento Cloud projects from composer.json or composer.lock.

[BUG] Coding Standard Baseline test fails on new classes

🐛 Bug report

Current Behavior

See action report https://github.com/mage-os/mageos-magento2/actions/runs/9672901395/job/26685992478?pr=97

• Committed a new php file/class QuoteAddress.php
• Submitted PR
• phpcs baseline test ran
• It attempted to load baseline version of QuoteAddress.php
• This failed because the file did not previously exist
• This caused the test to abort

Run php /home/runner/work/mageos-magento2/mageos-magento2/magento-coding-standard/vendor/bin/phpcs --standard=Magento2 \
  php /home/runner/work/mageos-magento2/mageos-magento2/magento-coding-standard/vendor/bin/phpcs --standard=Magento2 \
  $([ -n "5" ] && echo "--severity=5") \
  $([ -n "8" ] && echo "--warning-severity=8") \
  $([ -n "8" ] && echo "--error-severity=8") \
  --report=\\DR\\CodeSnifferBaseline\\Reports\\Baseline --report-file=phpcs.baseline.xml \
  app/code/Magento/Customer/Model/Plugin/UpdateCustomer.php app/code/Magento/Customer/etc/webapi_rest/di.xml app/code/Magento/Quote/Model/BillingAddressManagement.php app/code/Magento/Quote/Model/QuoteAddressValidator.php app/code/Magento/Quote/Plugin/QuoteAddress.php app/code/Magento/Quote/Plugin/ValidateQuoteOrigOrder.php app/code/Magento/Quote/etc/webapi_rest/di.xml app/code/Magento/Sales/Helper/Admin.php app/code/Magento/Sales/view/adminhtml/templates/order/comments/view.phtml app/code/Magento/Ups/Model/Carrier.php app/code/Magento/Webapi/Controller/Rest/InputParamsResolver.php dev/tests/api-functional/testsuite/Magento/Customer/Api/CustomerRepositoryTest.php dev/tests/api-functional/testsuite/Magento/GraphQl/Sales/RetrieveOrdersByOrderNumberTest.php dev/tests/api-functional/testsuite/Magento/LoginAsCustomerAssistance/Plugin/CustomerAfterPluginTest.php dev/tests/integration/testsuite/Magento/CatalogInventory/Model/StockItemSave/OnProductUpdate/ByProductModel/ByStockItemTest.php dev/tests/integration/testsuite/Magento/Cms/Controller/Adminhtml/Wysiwyg/Images/DeleteFilesTest.php dev/tests/integration/testsuite/Magento/Sales/Helper/AdminTest.php lib/internal/Magento/Framework/Filesystem/Test/Unit/Directory/PathValidatorTest.php lib/internal/Magento/Framework/Webapi/ServiceInputProcessor.php || /bin/true
...
ERROR: The file "app/code/Magento/Quote/Plugin/QuoteAddress.php" does not exist.

Run "phpcs --help" for usage information

Run cp /home/runner/work/mageos-magento2/mageos-magento2/base/phpcs.baseline.xml /home/runner/work/mageos-magento2/mageos-magento2/magento-coding-standard/phpcs.baseline.xml
cp: cannot stat '/home/runner/work/mageos-magento2/mageos-magento2/base/phpcs.baseline.xml': No such file or directory
Error: Process completed with exit code 1.

Expected Behavior

• phpcs should run on the full file having no prior version to generate a baseline from

Minimal reproduction of the problem with instructions

See current behavior

What is the motivation / use case for changing the behavior?

Broken test

Environment

N/A

[DOCS] Write a yaml processor which adds the actions to the root README

📄 Documentation Request

What were you doing?

I was trying to get an overview of every action.

Expected behavior

I would like to be able to see the list of actions in the README. However, humans are terrible at remembering things, so we often forget to add them to the root. We should automate this.

Existing Documentation

https://github.com/mage-os/github-actions/blob/main/README.md

[FEAT] Add support for `phpcs_path` phpcs in `coding-standard`

💡 Feature request

Feature Name

vendored phpcs

The Desired Behavior

I would like a flag called phpcs_path which allows skipping the installation of the phpcs by the action and instead using the installed phpcs from the project.

Your Use Case

As a developer, I want to skip unnecessary phpcs installation.

Prior Work

php-actions/phpunit#51 was where I originally got this idea from.

[FEAT] Add new `fail_on_warnings` to the `coding-standard` action

💡 Feature request

Feature Name

Allow Codesniff warnings

The Desired Behavior

As a developer, when I have PHPCS warnings, I don't necessarily want my CI pipeline to error. I would like something like:

fail_on_warnings:
    description: 'Whether action should fail on warnings or not, default to true (fails)'
    required: false

as an input to this action.

Your Use Case

As a developer, I want my ci pipeline to pass if there are PHPCS warnings but no errors.

[FEAT] Add PHP (8.2) Version Support

💡 Feature request

Feature Name

Add support for PHP 8.2
Add support for specifying the PHP version on which the action should be run

The Desired Behavior

I would like to specify the PHP version on which the action is run. For instance, I would like to run the Magento 2.4.6 tests on PHP 8.1 and PHP 8.2, because it supports both PHP versions.
This at least applies to the integration test action. Maybe it is helpful for others as well.

Your Use Case

Prior Work

This is possible with the extdn actions.

Environment

Magento version: X.Y.Z 
PHP Version version: X.Y.Z 


Others:

[BUG] Coding Standard Action should not checkout repositories

🐛 Bug report

Current Behavior

The Coding Standard does too much in regard to checking out repositories

Expected Behavior

This is bad action behavior, often the repo is already checked out.

What is the motivation / use case for changing the behavior?

Faster actions.

[DOCS] Write a yaml processor which converts the `actions.yml` to a table for READMEs.

📄 Documentation Request

What were you doing?

I was looking at actions and I want to know the inputs. However, I'm forced to read yml. I'd like to read markdown instead.

Expected behavior

See the inputs in the README.md and the actions.yml.

Existing Documentation

These are already documented, we just need a tool that will generate docs from the yml on every PR.

[FEAT] Support API and GraphQL tests

💡 Feature request

Feature Name

functional-api-tests

The Desired Behavior

As a developer, I want to run the API and GraphQL tests.

Your Use Case

Prior Work

Environment

Magento version: X.Y.Z 
PHP Version version: X.Y.Z 


Others: