All Travis test builds are currently failing due to no MySQL database being created. We get
$ mysql -e "create database $MODULE"
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2)
For an example see https://www.travis-ci.org/jonathan1055/rules
There was an external change sometime recently, I have had this with other modules. The simple fix is that MySql needs to be listed explicitly in the build parameters (maybe it used to be implicit). It just needs
services:
- mysql
Patch to follow
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | 3079297-13.set-threshold-for-allowed-deprecations.patch | 393 bytes | jonathan1055 |
Comments
Comment #2
jonathan1055 commentedPatch to get travis builds working again:
- add MySQL service
- remove core 8.3, 8.5 and 8.5
- add core 8.6, 8.7 and 8.8
- do not run the core 8.8 + PHP5.6 combo as this is no longer supported
-
composer run-script drupal-phpunit-upgradeto update to phpunit 6 when requiredComment #3
tr commentedYeah, @fago was the one who was using Travis to CI his GitHub-centered work. I don't have access to @fago's github, and so I've been doing everything on drupal.org with DrupalCI. Personally I don't see the need to do off-site CI anymore because DrupalCI now does pretty much everything and can be customized if you want something other than the default. In fact, I have been intending to remove .travis.yml entirely, since I don't use it, Rules doesn't use it, I can't maintain it and because it's obviously out of date.
However, if you think there is a need to keep it, I'm willing to commit any updates you think are necessary as long as the DrupalCI tests continue to pass.
Comment #4
jonathan1055 commentedI have raised #3079373: Primary testing on Github/Travis or Drupal.org? to discuss this, as it would be a major planning decision if we get rid of Github. Let's continue the discussion there.
Comment #5
jonathan1055 commentedPostponing this until we decide on the future use of Github/Travis.
Comment #6
tr commentedWell, it's not a change - it already happened, long ago. I have been running everything right here on Drupal.org for the past 18 months or so since I became the maintainer. I have given my reasoning in many issues over that time, and no one has expressed any concern about the change.
Comment #7
jonathan1055 commentedOK, agreed we keep drupal.org as the primary development location. However, for those who do want to use Github and Travis for their own debug and testing of Rules issues, it would be good to have a working .travis.yml file.
Attached is a patch which has the above changes, plus it gets the typed_data module from git.drupalcode.org/project/typed_data not github.com/fago/typed_data
My Travis build using this file runs the five tests (Core 8.6 with PHP5.6 and PHP7, Core 8.7 with PHP5.6 and PHP7 and Core 8.8 with PHP7). The tests now run and all the assertions pass, but there are failures because we are using some deprecated functions. However, that is all for other issues to resolve, at least we can now run Travis tests.
So as per your comment in #3 please would you consider committing this file, so that others can also use Travis if they wish :-)
Thanks.
Jonathan
Comment #8
jonathan1055 commentedForgot the new patch.
Comment #9
tr commentedYes, but there's nothing we can do about those because core hasn't backported those changes to all the currently-supported versions of core. See the following issues where we're tracking those deprecations:
#3045738: Convert entity manager service usage to split up services ( Part 2 ) when Drupal 8.8 becomes the lowest supported version
#3030295: 'context' deprecated in Rules @Condition annotation
#3030291: ConfigurablePluginInterface is deprecated in core 8.7.x
There may be a few other deprecations that I don't know about, but if so they're buried deep in the log showing the 15,000 deprecation warnings covered by the above three issues. That's unmanageable, so my plan is to just wait and fix these when we can fix them without causing Rules to break entirely on "supported" core installs.
Yep, like I said in #3, I have no problem with committing this, with the caveat that I can't maintain it - I won't know if it breaks, and I will need someone to provide a patch to fix it if it does break.
I'll leave the issue open for a few days before committing, in case you think of anything else that needs to be included in the patch.
Comment #11
tr commentedCommitted. Thanks!
Comment #12
jonathan1055 commentedThanks TR. I accept your point
I will take that on, and make sure it runs and provide a patch if required.
Comment #13
jonathan1055 commentedBefore this issue is closed, could you make another commit to .travis.yml please? I have found out how to let the tests pass even when there are deprecation warnings. This is good for the tests, as it will mean we can properly check code changes that cause test failures, as opposed to always having the tests fail even when the code-change/bug-fix is correct.
Currently at core 8.6 there is a total of 3,024 deprecation notices, at core 8.7 it is 11,531 and at core 8.8 it is 11,551. Therefore I have set the deprecation threshold to 11,551 as it will be useful to know when the number of deprecations increases. I will be alerted to the travis test failure and can investigate the problem.
If you'd like a new issue with more detail let me know, but I thought the simplest was to just add the new patch here. Thanks.
Comment #14
tr commentedYes I will do that when I get back. As I said those can't be fixed for a while so I agree it's best to find a way to ignore those.
Comment #15
jonathan1055 commentedThanks. No hurry for the commit. Marking RTBC to show it is ready.
Comment #17
tr commentedCommitted. Thanks.
Comment #18
jonathan1055 commentedThta's great. Thank you.