Earlier today, the tests for facets started failing.
https://www.drupal.org/pift-ci-job/159838
https://www.drupal.org/pift-ci-job/159836
In the earlier, passing tests, the DCI_AdditionalRepositories had search-api alpha 12 as an additional repository.
09:11:28 DCI_AdditionalRepositories=git,git://git.drupal.org/project/facets.git,8.x-1.x,modules/facets,1;git,git://git.drupal.org/project/search_api.git,8.x-1.0-alpha12,modules/search_api,1;
Later, that dependency is no longer added.
09:53:13 DCI_AdditionalRepositories=git,git://git.drupal.org/project/facets.git,8.x-1.x,modules/facets,1;
We didn't do any commits in that timeframe, so I don't think it's something I did.
Comments
Comment #2
drummI don't see the search_api dependency at http://cgit.drupalcode.org/facets/tree/facets.info.yml. Is the dependency somewhere else?
Comment #3
borisson_It's in http://cgit.drupalcode.org/facets/tree/tests/facets_search_api_dependenc..., it's not needed for all the code because we also support drupal core but we want to specifically test the search api integration as well.
Comment #4
drumm#2651854: Only look for dependencies for releases with specific project node types added
So modules in test directories are no longer checked for dependencies.
The way to add dependencies for tests is to use
test_dependenciesin info files, using the same syntax asdependencies. https://www.drupal.org/node/542202#dependencies has this documented for D7, but it doesn't look like this has made it forward to D8.Comment #5
drumm… it doesn't look like this has made it forward to D8 at https://www.drupal.org/node/2000204.
Comment #6
borisson_I tried that; but that dependency is still not added.
- http://cgit.drupalcode.org/facets/commit/?id=fe62240d1a7b3852f29e50065e9...
- https://www.drupal.org/pift-ci-job/161218
Comment #7
trobey commentedTest dependencies should still work. Attached is a screenshot of the dependencies. It looks like the test dependencies has not been updated since 8.x-1.0-alpha3. I will take a look and see why.
Comment #8
trobey commentedDrupal core 7.x and 8.x have a bunch of garbage modules and dependencies for testing the module code. I added the code to ignore tests so that these would not show up.
Comment #9
drummThe DrupalCI job running probably started faster than the dependencies being updated. I kicked off a new set of tests to confirm.
Comment #10
drumm#2400705-24: Outdated version of dependencies are installed on the test-infrastructure has a few more details.
Currently DrupalCI job parameters, including dependencies, are built and sent off within a minute. Dependencies are calculated after dev release packaging, which is on an every-5-minute cron. So adding new dependencies like this have a good chance of hitting this.
Comment #11
drummThis uncovered a new bug. The workaround is to remove the test_dependency on
search_api:search_api_test_dband run the tests again 5 or 10 minutes after commit.search_api:search_apiis sufficient to get the project.Since dependency parsing of tests was removed,
search_api:search_api_test_dbdoesn’t have results for recent releases, so it resolves to an older search_api release. This is added in addition to the current version from thesearch_api:search_apidependency.Possible improvements:
project_dependency_get_external_release_dependencies()orPiftCiJob::requestTest()dedupe on project so only one version (the more recent) of each project is attempted to be checked out.Comment #12
drummLooks like Facets is testing well now. Changing the category for the potential improvements in my last comment.
Comment #13
borisson_Yes it is, thank you very much!
Comment #14
trobey commentedIf I just parse the info.yml files in Drupal 8.0.1 I get
Elimination of info.yml files that are under directories tests and Tests get rid of a lot of the modules that are just used for testing. It is pretty unlikely contributed projects will have info.yml files under src/Tests and it is probably a bad idea to be requesting a dependency on a module in a test directory.
Comment #15
trobey commentedThere are no components or dependencies for Drupal 7.42 and Drupal 8.0.3. See attached screenshots. Any information on why these failed?
Comment #16
drummNot really. I spot checked another recent tagged release, and dependencies did get populated. I ran the job to rebuild the drupal project's dependencies and it completed without errors. I'll see if I can remember to look for this for the next core release so I can get the packaging logs.
Comment #17
drumm#2667704: Testbot is trying to checkout CTools twice and failing uncovered that the most recent ctools release wasn't parsed either, https://www.drupal.org/node/2663662. That's also too far ago, we don't have packaging console logs from that far ago. We do need to see if there is a pattern here.
Comment #18
drummThe Jenkins job to rebuild dependencies does
rm -rf /var/tmp/project_dependency_sourcecode_directory/avatars, which fixes the problem of the shared repo being corrupted somehow.Packaging uses the existing repo if it is there:
I couldn't spot any permissions issues. ‘bender’ (the robot) is the only user that interacts with these repositories on jenkins1 (the server). The whole repo is owned by that user.
Something about how that fetch runs or the previous commands used in the repo confuses Git quite a bit.
A quick, effective fix would be to rm -rf the work tree and start over if git fetch fails.
Comment #19
trobey commentedI have not dug much into this part of Project Dependency but it seems overly complicated. Code checked out from Git is persisted I suppose for efficiency reasons and then updated. But this seems to be rather prone to permission problems or just corruption. So it is a natural thing to view with suspicion when there are occasional failures.
Normal flow is process a release from one project and then a release from a different project and so on. The flow is not processing multiple releases from a single project except in special circumstances. So I do not understand what is gained by checking out the entire project. Why not check out just the code that is needed? To be concrete, use
git clone --depth 1 --branch ..
This just retrieves the requested branch instead of the entire code base.
Some time ago I coded up the following as a fallback if the fetch fails (this has not been committed):
But it would greatly simplify the code to just call this and not persist the checked-out code. Am I missing something here?
Comment #20
drummThat should work. I don't think maintaining the checkouts is necessary either. Must have been a premature optimization.
Comment #21
trobey commentedI uploaded a patch to simplify the git code so it checks out the branch and then removes the branch once the files are processed.
Comment #23
trobey commentedI created a new release with the changes. If there are any problems then you should be able to roll back the release.
Comment #24
drummThis has been deployed and looks like it is working well.