Appveyor stopped running my phpunit tests

Greg Anderson's Avatar

Greg Anderson

19 Oct, 2018 04:46 PM


PHPUnit used to work fine for me on Appveyor, and it is still working well locally and on Travis. On Appveyor, however, I am now getting a message "No tests executed".

By the symptoms, it seems that maybe PHPUnit is unable to find my phpunit.xml.dist file. I've tried a number of things, though, such as calling vendor/bin/phpunit directly, explicitly providing the path to my configuration file, etc., but to no avail. Anyone else have this problem, or know what the resolution is?

  1. 1 Posted by Owen McDonnell on 19 Oct, 2018 05:44 PM

    Owen McDonnell's Avatar

    Can you turn off caching and try running a build.

  2. 2 Posted by Greg Anderson on 19 Oct, 2018 10:02 PM

    Greg Anderson's Avatar

    I commented out the cache directives in my appveyor.yml file, and added a couple of environment vairables through the Admin API to prevent restoring and saving the cache. The rebuild is here:

    The results are the same.

  3. 3 Posted by Owen McDonnell on 19 Oct, 2018 10:32 PM

    Owen McDonnell's Avatar

    What if you go to the last build in which the tests were detected, and hit Rebuild Commit button?

    I notice that on some previous builds that worked the version of PHPUnit was 4.. while on the ones that fail it is 5... How is that version being set?

  4. 4 Posted by Greg Anderson on 19 Oct, 2018 10:57 PM

    Greg Anderson's Avatar

    I cannot rebuild old passing builds, because appveyor complains that the
    pull request is now closed.

    Here's an old failing build that is still on phpunit 4:

    phpunit is one of my composer dev dependencies; it is installed via
    Composer into vendor/bin.

        - Greg

  5. 5 Posted by Owen McDonnell on 20 Oct, 2018 01:19 AM

    Owen McDonnell's Avatar

    I have no precise understanding of how it's occurring but I strongly suspect the problem lies in the lock file, since, in builds in which the tests are discovered there is the warning in the logs Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.

    From what I can tell, in all the builds where the tests are ignored there is no such warning. Unless you have a counter example.

  6. 6 Posted by Greg Anderson on 21 Oct, 2018 01:57 AM

    Greg Anderson's Avatar

    I found a couple other project with a very similar configuration: same
    version of Composer, same version of phpunit, pretty similar setup. It
    works fine. Here's a successful build from each:

    I also found another project that is failing in the same way (phpunit
    claims there are no tests):

    I've looked at these projects and I can't figure out what's different
    between the ones that do not find their tests, and the ones that do.

    Also, I'm not sure if I already sent the message below to you:


    I ensured that the composer.lock file was up to date, and added --debug
    to phpunit to see if it would give any additional hints:

    The --debug flag did not show any useful information. This same command
    with the same phpunit and composer versions works fine.

          - Greg

  7. 7 Posted by Greg Anderson on 21 Oct, 2018 02:08 AM

    Greg Anderson's Avatar


    By inspection I couldn't see any difference between my projects that
    were failing, and those that were working, so I tried doing a full diff
    of the appveyor.yml file, and found one notable difference:

    --- appveyor.yml 2018-06-16 22:26:11.000000000 -0700
    +++ ../annotated-command/appveyor.yml 2017-07-20 14:42:12.000000000
    @@ -1,7 +1,7 @@
      build: false
    -shallow_clone: false
    +shallow_clone: true
      platform: 'x86'

    I switched 'shallow_clone:' to 'false' in my failing projects, and
    phpunit started working again.

    I can think of no reason why making a shallow clone of the project would
    affect the behavior of phpunit. I don't even know why any of my projects
    had 'shallow_clone: true', as I don't need anything but the top commit
    to test any of these projects; I'm just glad that they did, or I don't
    know that I ever would have found this.

    You may resolve this ticket; no further follow-up is required. You might
    wish to investigate further for your own edification, as in the past,
    'shallow_clone: true' worked for these projects.


         - Greg

  8. 8 Posted by Greg Anderson on 21 Oct, 2018 02:26 PM

    Greg Anderson's Avatar

    One last thought on this problem. My projects contain .gitattribute
    files with entries such as:

    /tests export-ignore

    If appveyor recently started to handle `shallow_clone: true` in a way
    that causes the resulting files to respect files with `export-ignore`
    set, that would be incorrect behavior. Packagist respects export-ignore
    to remove files that are not needed for distribution (tests and other
    development files), which is why these attributes are set in my
    projects. A test tool should not do the same thing.

    My opinion, anyway. The workaround is to not use the shallow_clone

          - Greg

  9. 9 Posted by Owen McDonnell on 23 Oct, 2018 05:11 PM

    Owen McDonnell's Avatar

    I think it is expected behaviour that If shallow_clone: is set to true, the directories and files that are marked as export-ignore in the .gitattributes file will not be included in the clone.

  10. Ilya Finkelshteyn closed this discussion on 23 Dec, 2018 09:00 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac

Recent Discussions

13 Dec, 2019 05:26 PM
13 Dec, 2019 11:28 AM
12 Dec, 2019 09:36 PM
12 Dec, 2019 09:25 PM
12 Dec, 2019 06:01 PM


11 Dec, 2019 11:29 PM
11 Dec, 2019 08:47 PM
11 Dec, 2019 01:39 PM
10 Dec, 2019 12:29 AM
09 Dec, 2019 05:35 AM
07 Dec, 2019 04:20 PM