Problem/Motivation
Unit tests should not require a database connection, but some in the suite currently do, therefore CI jobs enable the database services.
Steps to reproduce
Proposed resolution
Move the jobs that require a database away from the Unit testsuite, and drop the database service from the CI jobs.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3477529
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3477529-10.5
changes, plain diff MR !10021
- 3477529-ci-remove-the
changes, plain diff MR !9669
Comments
Comment #3
mondrakeComment #4
mondrakeComment #5
catchThis looks pretty reasonable to me. I was slightly concerned whether there might be a test where kernel test could 'hide' what might otherwise be a test failure for a uni test, but none of the tests look like that would be an issue.
Comment #6
mondrakeWell, the
Component*Testare clearly misplaced Kernel test - they extend fromComponentKernelTestBasewhich extends fromKernelTestBase. Should really not be under unit test namespaces.TestSiteApplicationTestrequires a CI database service, and should be run for each one of the core databases. Moving to Kernel seems the correct step.Once we remove the need for the CI database service, Unit tests could be run only once and not repeated for each database.
Comment #7
mondrakeRebased
Comment #8
smustgrave commentedWill this have any impact on contrib tests? May be a dumb question.
Comment #9
mondrakeNo, contrib tests are not organised in suites; each run include all of the test types. At least in our test setup on GitLabCI. This is only relevant for core CI testing AFAICS.
Comment #10
smustgrave commentedWill go out on a limb then and mark it.
Comment #13
catchCommitted/pushed to 11.x, thanks!
I think we should probably backport this to 10.4.x given we'll be running tests against 10.4 for a while yet. Doens't cherry-pick cleanly to 11.0.x either but not worried about backport there.
Comment #14
mondrakeis backport required for 10.5.x now, 10.4.x, or both?
Comment #15
mondrakeComment #17
mondrakeComment #20
catchCommitted/pushed to 10.5.x and went ahead and cherry-picked to the 10.4.x branch so that the (new) 11.1.x and 10.4.x branches have parity.
Comment #22
mondrake