We want to run our PHPUnit tests every time a patchset is pushed to the wikimedia/fundraising/crm repo. The only trick is to provision a MySQL database for use by the test. The following patch should manage databases correctly, and is compatible with the testing code within the repo:
Description
Description
Details
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T90630 Recurring Payments Reporting | |||
| Resolved | • mepps | T97372 Enable ability to look up contacts by phone number | |||
| Resolved | None | T77910 [epic] Upgrade Civi to 4.6 & integrate new reporting | |||
| Resolved | Ejegg | T89404 Create unit and integration tests for Fundraising extensions to identify breaking MediaWiki changes | |||
| Resolved | awight | T78100 Continuous integration - CiviCRM | |||
| Resolved | awight | T86103 CI for Civi: provision and run tests under Jenkins/Zuul | |||
| Resolved | awight | T86374 Deploy CiviCRM integration job to WMF integration server | |||
| Declined | awight | T88599 Create new labs project: fundraising-integration | |||
| Invalid | awight | T89894 Create and provision CI slave instance for CiviCRM testing | |||
| Resolved | awight | T90472 Add Fundraising Tech team to the labs Integration project | |||
| Resolved | awight | T89895 Configure Jenkins to run CiviCRM builds on Fundraising CI slave instance | |||
| Resolved | awight | T89896 Run CiviCRM testing scripts during CI |
Event Timeline
Comment Actions
Great, looking forward to it!
And, sorry to shout, I'm getting pressure to move forward with some heavy
lifting in this codebase, and the CI will make life much easier & the
future more secure :)
-a
Comment Actions
I hopefully managed to send an invite for Tuesday 1/20 at 10:00am PST :] Might want to bring other fundraising folks so we can talk about CI / Release in general or whatever other needs you might have.
Comment Actions
From a short discussion I had with Adam, you can create an instance and we can add it as a Jenkins slave. Then create a job that clone the repositories and apply the patchset then invoke a single command (example: ./runtests.sh ).
The labs instance would need to have the puppet class role::ci::slave::labs::common applied which adds a ferm rule (and thus some iptables firewall rules). That might have side effects.
Comment Actions
That sounds like a great plan. I'll assign this task to myself to create the labs instance, then pass it back for slaving.
Comment Actions
@hashar: Is there an existing security group I can use for the new instance? I'm not sure what the firewall should look like for a Jenkins slave.
Comment Actions
Following on discussions I had last week with Gabriel Wicke (for RestBase testing T78410) and Adam Wight.
We can get one or more dedicated labs instance that you can configure how ever you want via puppet and we can add it as a slave. Then configure a job that invokes a test entry point (ex: composer test or make or whatever else suit your needs) and only runs on that instance.
The only requirement should be applying the puppet class role::ci::slave::labs::common which set up the requirements to be able to add the instance to the Jenkins master.
I propose to get the labs project quota bumped a bit and create an integration-civicrm01.eqiad.wmflabs instance then add you guys to the labs project so you can set it up via puppet and add whatever you need.
Comment Actions
I'd really like it to be. It will make the upgrade much less risky if we
have some basic sanity checking.
The alternative is to manually run the tests, but that's not sustainable,
and requires a lot more dev overhead.
Comment Actions
Cool. Sounds good. I was going to say we should get all the blocking tasks
under T77910, but this is already blocking a blocker there (oy).
Thanks!
Comment Actions
Change 194986 had a related patch set uploaded (by Awight):
Let composer install the stuff
Comment Actions
Change 195002 had a related patch set uploaded (by Awight):
Correct mysql client machine name