laminas / laminas-ci-matrix-action Goto Github PK

Feature Request

Summary

In #58, we introduced the extension detection from composer.json.
However, I've seen a comment in #80 where a project had to add an extension to its .laminas-ci.json because it is required by a 3rd-party dependency.

I was thinking about that and I came to the conclusion, that it might be possible to iterate through the composer.lock packages to actually detect all PHP extensions from the require section of their composer.json.

Feature Request

Summary

Currently, one has to create plenty of exclude for PHPUnit for example.
Given the fact, that PHPUnit is executed in at least lowest and latest (and also locked for minimum supported PHP version), that would mean at least 3 entries within exclude to exclude a specific PHP version with all dependencies.

I'd like to suggest something like this (on top of the current way of excluding checks):

{
     "exclude": [
        {
             "name": "PHPUnit",
             "php": "8.0",
             "dependencies": "*",
        }
    ]
}

This would exclude all PHPUnit runs on PHP 8.0 with all composer dependencies.

Feature Request

Summary

I wonder if thats something we might want to add to allow projects to declare some stuff on the latest PHP version that project is supporting. I don't really have a use-case as of now but having this might probably open up some things for other projects.

So in the end, @highest or @latest in additional_checks would be converted to the highest supported version of a project (as detected in the config).

{
    "additional_checks": [
        {
            "name": "Output version of highest PHP version",
            "job": {"php": "@highest", "command": "php -v"}
        }
    ]
}

Would result in the following, if the php constraint is ^7.3 || ^8.0 (as of v1.10 which only can handle PHP 5.6 - 8.1):

{"php": "8.1", "command": "php -v"}

Feature Request

Summary

As suggested by @Ocramius on the laminas Slack: We could think about creating a monorepo for the matrix generation and CI container as they heavily depend on each other.
Even tho, its nice to decouple things, it might be worth merging both projects together.

We can build both containers from within one project and publish these to the github docker repository (I guess?).

Feature Request

Summary

Currently, the "checks" element is expected to be an object with the following schema:

{
  "name": "(string) Name of the check being run",
  "operatingSystem": "(string) Name of the OS the job should be run on (generally ubuntu-latest)",
  "action": "(string) GHA to run the step on; currently ignored",
  "job": "(string) JSON object detailing the job"
}

For configuration purposes, it would be easier if the "job" element of a check could be an actual JSON object:

{
  "name": "...",
  "operatingSystem": "..."
  "action": "..."
  "job": {
    "php": "php version",
    "extensions": [],
    "ini": [],
    "dependencies": "...",
    "command": "..."
  }
}

Each of "extensions", "ini", and "dependencies" are technically optional, but SHOULD be provided; I'd suggest we raise a notice of some sort in the action if they are missing.

For BC purposes, we should allow either a JSON string OR an object.

Feature Request

Summary

In #62, a CI pipeline was created for this action.
Sadly, the output of the integration tests diff are not that easy to understand.

I was thinking of using something like https://github.com/josephburnett/jd

Another "problem" is, that every check has a job property which contains the job as a stringified JSON.
Maybe this might be also fixed with using jd and maybe with a colorized output (not sure if thats even possible for GHA) but if not, using diff to actually do the diff might suffice while using jd to display some kind of "pretty printed JSON".

Feature Request

Summary

Currently, the .laminas-ci.json file allows you to specify a "checks" key, which is an array of checks to run. When defined, it specifies your entire matrix to run; the action does no discovery of its own at that point.

Sometimes, however, you may only want to add one or more checks to perform in addition to any that were discovered. As an example, this could solve the problem presented in #4, which requests the ability to run code coverage reports, or a scenario where you want to run an integration test suite that's normally excluded from your unit tests.

My proposal is to allow the following additions to the .laminas-ci.json format:

{
    "additional_checks": [
        {}
    ]
}

where each object in the additional_checks array has the following format (same format as individual items in the matrix):

{
      "name": "(string) Name of the check being run",
      "operatingSystem": "(string) Name of the OS the job should be run on (generally ubuntu-latest)",
      "action": "(string) GHA to run the step on; currently ignored, as GHA does not support dynamic action selection",
      "job": "(string) JSON object detailing the job"
}

Only "name" and "job" would be required; the other items could use defaults.

The "job" would then follow the same format as jobs currently do:

{
  "php": "string PHP minor version to run against",
  "extensions": [
    "extension names to install; names are from the ondrej PHP repository, minus the php{VERSION}- prefix",
  ],
  "ini": [
    "php.ini directives, one per element; e.g. 'memory_limit=-1'",
  ],
  "dependencies": "dependencies to test against; one of lowest, locked, latest",
  "command": "command to run to perform the check",
}

with the following rules:

• "php" would be optional; if not provided, the assumption would be to use the "stable-php" version
  • Nice to have: "*" to mean run against all versions; the check gets cloned, with each version using a different PHP version
• "extensions" is optional; if not provided, an empty array will be used
• "ini" is optional; if not provided, an empty array will be used
• "dependencies" is optional; if not provided, the assumption is to use "locked"
  • Nice to have: "*" to mean run against each of latest, locked, and lowest
  • Nice to have: allow an array of values; if an array is present, one job is created per PHP version
• "command" is required

This would give consumers more flexibility in defining one-off checks, or to run checks that we do not yet have the ability to detect in the container.

Feature Request

Summary

As of now, we are using some semver javascript library. Since that actually does not align with all the "features" of composer, we might want to create a little PHAR which uses composer/semver under the hood to simply exit with 0 if PHP version is supported by the constraint or 1 if not.

Adding some kind of child_process to our matrix javascript node binary and we can run that PHAR from within JS for a more accurate version detection.

This would also fix #86

Thoughts?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Edited/Blocked

These updates have been manually edited so Renovate will no longer make changes. To discard all commits and start over, click on a checkbox.

• Update dependency @typescript-eslint/eslint-plugin to v7
• Update dependency @typescript-eslint/parser to v7
• Update dependency eslint to v9
• Lock file maintenance

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update node Docker tag to v22

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Bug Report

Summary

When adding .laminas-ci.json or when changing that file, I would expect that the matrix generates all jobs as:

1. there could be new jobs added with additional_checks
2. existing jobs are being excluded using exclude
3. existing jobs are being overridden with checks

boesing/psalm-plugin-stringf#15
https://github.com/boesing/psalm-plugin-stringf/actions/runs/1226396745

Current behavior

No checks are generated.

How to reproduce

Create a PR with only changes applied to .laminas-ci.json

Expected behavior

The matrix would create the same changes as done in non-PRs.

Bug Report

As found in #134, we use node:^18 in package.json and node:19 in Dockerfile.

NPM happily keeps installing everything with a warning:

 #13 1.580 npm WARN EBADENGINE Unsupported engine {
#13 1.581 npm WARN EBADENGINE   package: undefined,
#13 1.581 npm WARN EBADENGINE   required: { node: '^18' },
#13 1.581 npm WARN EBADENGINE   current: { node: 'v19.0.0', npm: '8.19.2' }
#13 1.582 npm WARN EBADENGINE }

That's why I kept going and released 1.19.0 anyway: for 1.20.0 we should fix the dependency range.

Feature Request

Summary

While working on laminas/laminas-hydrator#95 I had to completely exclude my new code in psalm.xml, since the component supports PHP 8.0 but the code uses a PHP8.1 feature (enums). I think it would make sense to run Psalm on the highest stable PHP version so new features can be covered.

Bug Report

Summary

the semver version parser does not work correctly if composer.json uses this format "php": ">=7.4, <8.2", which prevents certain jobs from being created.

Current behavior

How to reproduce

setup a repo with a composer.json file with "require": {"php": ">=7.4, <8.2"} .

Expected behavior

Generate jobs for PHPUnit on PHP 7.4, 8.0, & 8.1

Bug Report

Summary

Given following composer.json:

{
    "require": {
        "php": "~8.1.0",
        "ext-pdo_sqlite": "*"
    }
}

CI fails with:

Run laminas/laminas-continuous-integration-action@v1
/usr/bin/docker run --name ghcriolaminaslaminascontinuousintegration1_e9f03a --label 94859b --workdir /github/workspace --rm -e INPUT_JOB -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_RUN_ATTEMPT -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_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 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/event-sourcing-workshop/event-sourcing-workshop":"/github/workspace" ghcr.io/laminas/laminas-continuous-integration:1  "{\"command\":\"./vendor/bin/phpcs -q --report=checkstyle | cs2pr\",\"php\":\"8.1\",\"extensions\":[\"pdo_sqlite\",\"sqlite3\"],\"ini\":[],\"dependencies\":\"locked\",\"ignore_platform_reqs_8\":false,\"ignore_php_platform_requirement\":false,\"additional_composer_arguments\":[]}"
Received job: {"command":"./vendor/bin/phpcs -q --report=checkstyle | cs2pr","php":"8.1","extensions":["pdo_sqlite","sqlite3"],"ini":[],"dependencies":"locked","ignore_platform_reqs_8":false,"ignore_php_platform_requirement":false,"additional_composer_arguments":[]}
Marking PHP 8.1 as configured default
Cloning repository
Cloning into '.'...
Checking out ref feature/working-prototype
Switched to a new branch 'feature/working-prototype'
Branch 'feature/working-prototype' set up to track remote branch 'feature/working-prototype' from 'origin'.
Installing packaged extensions: php8.1-pdo_sqlite php8.1-sqlite3 

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Get:1 https://packages.microsoft.com/ubuntu/20.04/prod focal InRelease [10.5 kB]
Get:2 http://ppa.launchpad.net/ondrej/php/ubuntu focal InRelease [23.9 kB]
Get:3 http://security.ubuntu.com/ubuntu focal-security InRelease [114 kB]
Hit:4 http://archive.ubuntu.com/ubuntu focal InRelease
Get:5 http://archive.ubuntu.com/ubuntu focal-updates InRelease [114 kB]
Get:6 https://packages.microsoft.com/ubuntu/20.04/prod focal/main amd64 Packages [203 kB]
Get:7 http://archive.ubuntu.com/ubuntu focal-backports InRelease [108 kB]
Get:8 http://ppa.launchpad.net/ondrej/php/ubuntu focal/main amd64 Packages [175 kB]
Get:9 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages [2087 kB]
Get:10 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages [2542 kB]
Get:11 http://archive.ubuntu.com/ubuntu focal-updates/restricted amd64 Packages [1571 kB]
Get:12 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages [1176 kB]
Get:13 http://security.ubuntu.com/ubuntu focal-security/universe amd64 Packages [888 kB]
Fetched 9012 kB in 3s (2992 kB/s)
Reading package lists...
Building dependency tree...
Reading state information...
30 packages can be upgraded. Run 'apt list --upgradable' to see them.

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package php8.1-pdo_sqlite

This is obviously an edge case, but even specifying extensions in .laminas-ci.json doesn't help, as the default behavior still stays active

Bug Report

Summary

It seems that the node dependency @cfworker/json-schema is not installed when matrix generation ramps up.

Current behavior

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/action/node_modules/@cfworker/json-schema/src/types' imported from /action/index.js

How to reproduce

Run matrix generation on any project on github which uses this action.

https://github.com/boesing/psalm-plugin-stringf/pull/8/checks?check_run_id=3309644575

Expected behavior

Matrix generation works as expected.

Feature Request

Summary

It would be great to have a way to mark extensions as optional, to be able to test with the extensions and without the extensions.
This way is possible to test if the code works correctly when the optional extension is not installed.

Maybe a new configuration key like optional_extensions.

• Related to laminas/laminas-serializer#49

Bug Report

Summary

It seems that for pull requests, which are created from the same branch in the forked repository, it is not possible to create a diff for the matrix generation.

Current behavior

Target branch: 1.2.x
Project branch: 1.2.x

Cloning into '.'...
Cloning repository
Checking out branch 1.2.x
Already on '1.2.x'
Your branch is up to date with 'origin/1.2.x'.
Fetching target ref refs/pull/7/merge
fatal: Refusing to fetch into current branch refs/heads/1.2.x of non-bare repository

https://github.com/laminas/laminas-mvc-i18n/pull/7/checks?check_run_id=2254661339

How to reproduce

Fork a repository, do not create a dedicated feature/bugfix/whatever branch but push to the same branch, the PR is targeted to later on.

Expected behavior

Matrix generation works without conflicting when creating a diff.
Works when the source branch differs: https://github.com/laminas/laminas-mvc-i18n/pull/10/checks?check_run_id=2254711601

Feature Request

Summary

As of now, we are only integration testing this component by directly executing the main.js which is build inside the container.
However, I've tested the latest v1.12.0 release in one of my projects and directly got the issue which was fixed with #96

This ticket is to keep track that we need a more integrated way of testing this component.

Feature Request

Summary

As of now, stable PHP version default option in this container is PHP 7.4.
Since 7.4 is moved to EOL on 2022-11-28, we should modify the default PHP version in this container to PHP 8.0 as new stable.

Bug Report

The laminas/laminas-continuous-integration action was incorrectly specifying laminas-ci-matrix as its tag prefix, which led to it overwriting the v1 tag for this action.

We simply need to force a new release.

Feature Request

Summary

The .laminas-ci.json allows to pass checks which overrides the additional_checks and thus are mutually exclusive. This makes the JSON schema more bloated as we have to provide two configuration combinations with either checks or additional_checks.

The .checks[].job element has is allowed to be a string which also makes it more error-prone.
It also states that it is possible to select an additional "action" which can be used with the CI matrix which is actually not really true as if someone choses another "action", that action also have to parse the job JSON-string and from this perspective, I dont really see the benefit of having checks.

Due to the fact that .checks[].job is a string, it also cannot be validated by the JSON schema which is feature-requested in #49.

Is there any project around which uses the .checks functionality from .laminas-ci.json? If not, I would prefer getting rid of that to simplify the matrix action.

Feature Request

Summary

https://github.com/Roave/BackwardCompatibilityCheck helps in guaranteeing that no accidental BC breaks land in existing code in minor/patch releases.

My suggestion is to add a CI action that:

• runs https://github.com/Roave/BackwardCompatibilityCheck on pull requests
• compares the last release (default behavior) with the current HEAD

This could be a bit trickier than usual, because:

• we need to git fetch the latest release, as well as HEAD
• we need to make sure we're comparing HEAD against the correct release: depends on the target branch of a pull request

RFC

While running tests over the last few days, I noticed that we have test failure due to runtime depreciations (which I still firmly believe to be an abomination) when running latest dependencies against the lowest supported PHP version of a repository.

We have to consider 2 problems in this test matrix entry:

1. lowest PHP version will hardly ever receive latest dependencies anyway
2. we refresh the composer.lock of all repositories on a nightly basis, therefore detecting upstream breakages

Given that updating lock files is equivalent to testing latest dependencies, I therefore suggest dropping the latest entries from our generated CI matrix.

Note: I counted this as BC break, because it changes assumptions around testing depth

Feature Request

Summary

Tools binaries might be in a different location than /vendor/bin.

We could a support for the config.bin-dir options in composer.json

This outputs the current set location.

composer config 'bin-dir'

Bug Report

This was first discovered in mezzio/mezzio-swoole#128

Summary

Matrix fails with unintelligible error when composer.json is invalid.

Expected behavior

Matrix generation should fail with an error message such as 'Cannot generate matrix. Invalid composer.json detected'

Feature Request

Summary

Add a check to the configuration reading for laminas/*, mezzio/* and laminas-api-tools/* components regarding the backwardsCompatibilityCheck flag.
If that flag is not explicitly set to false in project configuration files, we want to enable it for packages of the orgs mentioned above.

Feature Request

Summary

It might be handy to have org-wide configuration available for CI stuff. Renovate for examples allows config merging with organization config:

https://github.com/laminas/.github/blob/main/renovate-config.json
https://github.com/laminas/laminas-servicemanager/blob/c97780e74ac5c2fdf2aa4876bccdc718b6fc6ed9/renovate.json#L4

The idea of this feature request is to allow .laminas-ci.json files being available in the .github repository as well.
Once it is available, its being merged.
It should not be dependend on a config entry (as most projects do not even have .laminas-ci.json in-place.
So I'd always check the organization for having a .laminas-ci.json and if so, that is used as a default and then merges explicit configuration with the project file (if available).

Feature Request

Summary

composer-require-checker is a useful tool for ensuring that composer.json contains all the necessary required packages. It is advised to be used as a standalone tool, or as globally installed, not as a development dependency.

Ideally this should be installed into this action as a PHP tool, however this is dependent on the resolution of #119.

Bug Report

Summary

Initial git clone fails for private repositories

Current behavior

Run laminas/laminas-ci-matrix-action@v1
/usr/bin/docker run --name ghcriolaminaslaminascimatrix1_c6d[2](https://github.com/plhw/lab-api-model-valueobject/runs/8200006290?check_suite_focus=true#step:3:3)87 --label 786a9b --workdir /github/workspace --rm -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -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_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 "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/lab-api-model-valueobject/lab-api-model-valueobject":"/github/workspace" ghcr.io/laminas/laminas-ci-matrix:1
Cloning into '.'...
Cloning repository
fatal: could not read Username for 'https://github.com/': No such device or address

How to reproduce

1. create a private repository on github
2. add this workflow https://github.com/laminas/workflow-continuous-integration
3. Add GITHUB_TOKEN as environment variable to the steps
4. push

Expected behavior

Initial checkout succeeds

Notes

• edited: added step 3
• I've checked the token permissions on https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-the-default-github_token-permissions
• Been reading this https://docs.github.com/en/actions/security-guides/automatic-token-authentication#about-the-github_token-secret
  • looking at the example they set and use the token differently. That might be a clue as git won't use the GITHUB_TOKEN env variable by itself.

Shouldn't the auth token be persisted to the local git config before it can be used by git commands? actions/checkout action seems to do that (See the Readme).

Feature Request

Summary

It would be really cool to detect or configure the ability to report coverage after successful PHPUnit actions. I guess these would be vendor specific?

Most laminas repos seem to use coveralls and have an existing coveralls.yml file. I personally tend to favour codecov which can use a config file but doesn't require one.

Is this a feature that you might consider?

Feature Request

Summary

This action is currently parsing project configurations and ignores badly formatted jobs while adding a warning to the output.

I would prefer having a check fail. This could be done by creating a JSON Schema along with a Schema validation as done for composer.json (as of 1.8.0).

WDYT?

We could also add a JSON schema to the container action and re-use it in here for output validation (as part of CI of this container).

Feature Request

Summary

Currently, if the diff only contains a change for phpunit.xml.dist or infection.json (etc.), no checks would be generated.
With #83 it would be quite easy to enable specific tool checks for the diff.

Maybe this issue should be renamed to "only enable checks for tools which do match the diff (if a diff is available)". For now, this Ticket is just to keep track of ideas which came up during the development of #83.

Bug Report

Summary

When I've impelemented the ignore_php_platform_requirements feature, the main idea was to get rid of the old and yet deprecated ignore_platform_reqs_8 feature, which defaulted to true.

I was assuming (and thought I've implemented it that way 😅) that when adding an empty ignore_php_platform_requirements object to the .laminas-ci.json, we do not explicitly mark PHP 8.0 as true.
Sadly, it does and thus, I'd like to either change this and/or remove ignore_platform_reqs_8 entirely.

ignore_php_platform_requirements option is available since v1.9.0 (released in 08/2021)

Current behavior

Adding an empty ignore_php_platform_requirements does not prevent ignoring platform reqs for PHP 8.0.

How to reproduce

Add an empty ignore_php_platform_requirements to the .laminas-ci.json in a project with PHP 8.0 support and check matrix output. It contains ignore_php_platform_requirement: true for PHP 8.0.

Expected behavior

ignore_php_platform_requirement should be false for PHP 8.0.

Bug Report

Summary

When a component uses a more complex constraint which contains ,, the matrix is not able to infer supported PHP versions anymore.

Current behavior

Supported PHP versions are not detected at all.

How to reproduce

composer.json

{
    "require": {
        "php": ">=5.6,<=8.1.99"
    }
}

Expected behavior

All versions between PHP 5.6 and 8.1.99 are detected. As of writing this issue, this would be:

• 5.6
• 7.0
• 7.1
• 7.2
• 7.3
• 7.4
• 8.0
• 8.1

Feature Request

Summary

Whenever we make small adjustments to our codebase, we may improve type information.

It may be a good idea to reduce our psalm-baseline.xml accordingly, when possible.

The rough idea is that:

1. a new change is pushed to the main configured branch (to be detected by CI)
2. the change removed one type error somewhere
3. we run vendor/bin/psalm --update-baseline, which should reduce the contents of psalm-baseline.xml (if it exists)
4. if changes are produced by this pipeline, commit them
5. push these changes to a reserved branch
6. run CI on that branch
7. auto-merge to main branch

This is extremely elaborate, compared to our current CI tasks, so it requires a lot of added engineering work around the pipeline, but it can probably be done :-)

Bug Report

Summary

I am currently working on providing integration tests in #62
There, I've seen that @lowest and @latest is not properly handled by the matrix action when it comes to explicit checks provided by the projects .laminas-ci.json

Current behavior

When @lowest and/or @latest is used for job.php, the action does skip that job:

::warning::Invalid job provided; no PHP version or unknown PHP version specified: {"php":"@lowest","dependencies":"locked","command":"vendor/bin/phpunit"}
::warning::Invalid job provided; no PHP version or unknown PHP version specified: {"php":"@latest","dependencies":"locked","command":"vendor/bin/phpunit"}

How to reproduce

.laminas-ci.json

{
    "checks": [
        {
            "name": "PHPUnit with locked dependencies on lowest supported PHP version",
            "job": {
                "php": "@lowest",
                "dependencies": "locked",
                "command": "vendor/bin/phpunit"
            }
        },
        {
            "name": "PHPUnit with locked dependencies on lowest supported PHP version",
            "job": {
                "php": "@latest",
                "dependencies": "locked",
                "command": "vendor/bin/phpunit"
            }
        }
    ]
}

Expected behavior

Matrix does not report a warning for @lowest or @latest and properly uses the lowest and latest supported PHP version by the project within the job declaration.

Feature Request

Summary

I do use additional_checks quite often and I wonder if we should allow some kind of additional (optional) configuration to declare files to check so that these checks are (if defined) only generated when these files have changed in diff.

Thoughts?

Ref:

It seems that the way how we (I) implemented the tests in this project might become invalid at some point in time.
I've recently seen the output of one of the tests within a PR and it says:

Warning: The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

I just create this ticket as a reminder that there is a TODO but unfortunately I don't have time as of right now to work on this right now.

RFC

Goal

I think it would be quite helpful to use shivammathur/php-builder to early create issues and PRs to add support for PHP 8.1 so we do not have the same mess as with PHP 8.0 which is still not yet finished (no blaming, we are just lacking contributions - thats all).

Background

Due to the usage of usage of https://github.com/oerdnj/deb.sury.org, we are currently limited to the versions Ondřej supports.
For PHP 8.0, he requested funding to make it available (oerdnj/deb.sury.org#1439 (comment), no blaming) and in the end, PHP 8.0 was installable (thankfully to laravel and/or seravo) around 2020-10-05.

https://github.com/shivammathur/php-builder on the other end had PHP 8.0 available around december 2019.

Having PHP 8.1 available in October or later within sury repository (he states that he always waits for a first beta RC), we will lack a bunch of months to catch up until november.

Considerations

The impact on users would be nearly none as the PHP versions are just consumed and build from the same source. Thus, for the enduser, nothing will change.

Proposal(s)

Users will consume the docker images as before.

Appendix

Instead of pre-building Ondřej PHP to our docker images, we should use Shivam's php-builder instead so we can probably start creating branches which support PHP 8.1 as of now.

I am not sure if its possible to setup cron-like workflow triggers based on Open PRs which might be flagged by a specific label?
Probably, creating a dedicated label for early-php-support will always execute PRs automatically once a month until merged?

Any feedback is welcome.

Bug Report

Summary

When Psalm is installed using psalm/phar instead of vimeo/psalm, an error occurs because vendor/vimeo/psalm/config.xsd does not exist.

refs #31, psalm/phar#5

Current behavior

Running before_script: xmllint --schema vendor/vimeo/psalm/config.xsd psalm.xml
warning: failed to load external entity "vendor/vimeo/psalm/config.xsd"
<?xml version="1.0"?>
Schemas parser error : Failed to locate the main schema resource at 'vendor/vimeo/psalm/config.xsd'.
WXS schema vendor/vimeo/psalm/config.xsd failed to compile
<psalm xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="https://getpsalm.org/schema/config" errorLevel="1" resolveFromConfigFile="true" xsi:schemaLocation="https://getpsalm.org/schema/config vendor/vimeo/psalm/config.xsd" errorBaseline="psalm-baseline.xml" findUnusedBaselineEntry="true" findUnusedCode="false">
    <projectFiles>
        <directory name="src"/>
        <ignoreFiles>
            <directory name="vendor"/>
        </ignoreFiles>
    </projectFiles>
</psalm>

How to reproduce

In a project where psalm.xml exists, replacing vimeo/psalm with psalm/phar will reproduce the problem.

michaelpetri/phpunit-consecutive-arguments#109

Expected behavior

No errors.

Feature Request

Summary

Hi, I'd like to add to every matrix one with the purpose of linting composer.json. In Paratest we use 4 steps:

Feature Request

Summary

Hey there,

I am currently working on something and I have the following use-case:

• run tests on all supported PHP versions (works out-of-the-box)
• run tests on lowest PHP version with locked deps (works ootb)
• run tests on lowest PHP version with locked deps via additional_checks (works ootb, but...)

So the latter does work due to prior changes made to this action. The problem is, that I now want to identify this exact additional_check somehow. Because the main idea of this check would be:

Run tests on lowest PHP version with locked deps but disable one or more PHP extensions (to see if tests are still passing due to precautions or polyfills) and/or disallow PHP functions.

So, I'd like to have some kind of optional name within the job configuration which can be used as some kind of unique identifier. When added, this can be extract within a pre-run.sh for example.
An alternative would be to actually allow disabling extensions via the job array. That would make the whole thing easier but maybe its worth having both "features" up and running.

WDYT?

Feature Request

Summary

We do have a few components where we actually implement specific interfaces, such as PSR ones.
We had a release for laminas-servicemanager which stated to support psr/container v2 support. That was incorrect, due to several things:

1. the composer.json did not provide support for ^2.0 of the psr/container package via psr/container-implementation.
2. the composer.lock did not contain the latest version of psr/container since it got blocked by a 3rd-party library which did not supported psr/container v2 yet (but was only added as a dev-dependency)

At least due to the 2nd issue, all tests were passing and thus the PR got merged.

So what we could try to do is:

1. use diff to find those packages which were changed
2. use jq to extract provide packages
3. compare provide constraint with require constraint

Or maybe something else. I'll keep this here to keep track of my ideas.

This component does not really use OOP in most places and thus, providing logging and stuff is quite complicated.

To solve this, we can implement a dependency injection library.

I do quote the answer from @internalsystemerror here as he provided some information on how we could move over to dependency injection.

I'm mostly familiar with the DI in Angular, but there are (smaller) libraries available e.g. TypeDI or even TSyringe by MS

Originally posted by @internalsystemerror in #119 (comment)

Feature Request

Summary

Currently, the .laminas-ci.schema.json is written manually. We can automate this by using https://www.npmjs.com/package/typescript-json-schema instead.

Relates to #54

Summary

Flag was introduced with 1.23.0 but I actually missed to properly add it to the documentation (README.md) though it is part of the configuration schema:

Feature Request

Summary

As noted in #4, laminas/laminas-continous-integration-action already supports the possibility of using the action in conjunction with action/checkout; the relevant bits are here.

The entrypoint for the container supporting this action should be updated similarly.

Feature Request

Summary

As discussed in laminas/automatic-releases#118, we want to include infection and roave/infection-static-analysis-plugin to matrix here - so that we can also make automatic-releases use our brand new CI matrix process.

The only thing we need to verify is when to add the infection, or roave/infection-static-analysis-plugin, or both to the build matrix.

Feature Request

Summary

This component supports some tools for CI pipeline, such as:

• PHPCodeSniffer
• Psalm
• PHPUnit
• PHP-CS-Fixer
• etc.

(List of supported tools can be found in this file)

At least for one tool (PHP-CS-Fixer), we require a project to have a composer-require-checker.json configuration file available. This is because the tool does not have a default filename for this and thus, we decided to go with this filename.

For infection, we do support the static-analysis tool from Roave as well, but do not list it anywhere in the README or docs.

So this Issue is to ensure we do improve the documentation of this github action so that every1 who wants to use this CI Pipeline is aware of how to configure the project.

Feature Request

Summary

1. Run composer validate to confirm that there are no issues with the composer.json file.
2. Run composer check-platform-reqs, at least where --ignore-platform-reqs is not used in order to confirm that the installed packages should function correctly.
3. Run composer audit to get a list of the vulnerable packages (if any) as the warning on install just lists the number of vulnerable packages, not what they are https://github.com/laminas/laminas-cli/runs/8005445567?check_suite_focus=true#step:3:315