8000 GitHub Actions tweaks by morozov · Pull Request #6952 · doctrine/dbal · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

GitHub Actions tweaks #6952

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 13, 2025
Merged

GitHub Actions tweaks #6952

merged 2 commits into from
May 13, 2025

Conversation

morozov
Copy link
Member
@morozov morozov commented May 12, 2025

A recent nightly run indicated a couple more issues with the workflow:

  1. The pdo_oci build on PHP 8.5 still failed but in a way different than before:
    1. The failure to set up PHP didn't immediately fail the job:
    ==> Setup PHP
    ✓ PHP Installed PHP 8.5.0-dev (e[11](https://github.com/doctrine/dbal/actions/runs/14976899880/job/42092146138#step:4:12)a702c0569a2b5a2282fcba4862731ebfb91a3)
    
    ==> Setup Extensions
    ✗ pdo_oci Could not install pdo_oci on PHP 8.5.0-dev
    
    ==> Setup Tools
    ✓ composer Added composer 2.8.8
    
    1. All integration tests failed with the same error message:
    There were 975 errors:
    
    1) Doctrine\DBAL\Tests\Driver\Mysqli\ConnectionTest::testHostnameIsRequiredForPersistentConnection
    Doctrine\DBAL\Exception\DriverException: An exception occurred in the driver: could not find driver
    
    ...
    
    975) Doctrine\DBAL\Tests\Functional\WriteTest::testDeleteWhereIsNull
    Doctrine\DBAL\Exception\DriverException: An exception occurred in the driver: could not find driver
    
  2. The failure of the pdo_oci job canceled the oci8 one (I restarted it manually).

The first issue is solved by running shivammathur/setup-php with fail-fast: true (documentation). I don't know how it worked in the continuous-integration workflow without this flag and why it's not the default behavior. Even if it was the global fail-fast: true environment variable that defined the behavior of the setup action, it should have defined in the nightly workflow as well.

The second issue is addressed by removing fail-fast: true from the nightly workflow. We don't need to optimize the workflow runtime there, and if one job against a given database platform fails, it doesn't mean that the others would and thus should be canceled (the focus is on testing unstable dependencies, not the code).

@morozov morozov added the CI label May 12, 2025
@morozov morozov marked this pull request as ready for review May 12, 2025 22:57
@morozov morozov requested a review from greg0ire May 12, 2025 22:57
@morozov morozov added this to the 3.9.5 milestone May 13, 2025
@morozov morozov merged commit c83645d into doctrine:3.9.x May 13, 2025
51 checks passed
@morozov morozov deleted the github-actions-tweaks branch May 13, 2025 15:31
@morozov morozov mentioned this pull request May 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0