Right now, when a new release or versioncontrol_arrival event takes place, there is one module that creates a git clone of the project, and introspects some files in that project for metadata - project_dependency.
project_dependency is only looking at .info and .info.yml files, and helping to build the dependency graph for the composer facade.
However, it would be nice if there was a separate module responsible for cloning the repository, and firing a hook such that any other module in the system could look for files that are important to it.
For example, we are going to start offering developers the ability to include a drupalci.yml file in their codebase, and project_issue_file_test is probably going to need to gather those files from the filesystem and store them.
Additionally there are other projects that do not have an info.yml file that could benefit from having their composer.json files stored in the repo much like the project_dependency components are stored, so that they too can be part of the composer facade (drush extensions, database plugins, libraries etc)
Comments
Comment #2
MixologicComment #3
MixologicA good use case for this would be to pull in README.txt/README.md files and store them in a field on a project.
Comment #4
drummComment #16
MixologicThis has been deployed.
Comment #17
markhalliwellI'm confused... did this actually create a
drupalorg_repository_investigator
module? It seems all the above commits just changeddrupalorg_versioncontrol/drupalorg_versioncontrol.module
to add a new hook.This doesn't really provide an API for "investigating" a repository does it? I mean I'm OK with this if it was intended... but it just appears to be counter to/incomplete of what the issue title indicated is all.
Comment #18
MixologicThe only thing this was meant to do was to provide a checked out working directory of a git repo on the filesystem, and pass that along a hook to anything else that wanted to care about the repo contents.
Originally it was going to be a module on its own, but we realized that it didnt really need to be, and that we already had an appropriate module where this could live. As far as an API goes, well, its a filesystem, and theres already a lot of api's for interacting with the filesystem, and the hook implementors get access to the versioncontrol_repository object as well, which can give any of the required repo metadata.
Now that we have that hook, we'll be able to implement it in various places. (And potentially do different things, depending on the file we're inspecting)
So for drupalci, we'll be looking per branch at drupalci.yml files. For the README.md we might only save the one from the default branch. And we might pre-render the markdown into html and cache that somehow. But now, at least, we have the repo that we can introspect, and we can decide what to do with it on a case by case basis.
Comment #19
markhalliwellSure that makes sense, just double checking is all. Changing title to reflect what was actually done and for clarity/posterity sake.