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

Mixologic created an issue. See original summary.

Mixologic’s picture

Mixologic’s picture

A good use case for this would be to pull in README.txt/README.md files and store them in a field on a project.

drumm’s picture

  • 95b5f0a committed on 2949200-add-repository-checkout-hook
    Issue #2949200: Checks out a repository and passes it to a hook so that...

  • 95b5f0a committed on 2949200-add-repository-checkout-hook
    Issue #2949200: Checks out a repository and passes it to a hook so that...

  • 95b5f0a committed on 2949200-add-repository-checkout-hook
    Issue #2949200: Checks out a repository and passes it to a hook so that...

  • 95b5f0a committed on 2949200-add-repository-checkout-hook
    Issue #2949200: Checks out a repository and passes it to a hook so that...

  • c86f7f1 committed on 2949200-add-repository-checkout-hook
    Issue #2949200: removed some cruft
    

  • ec0be2f committed on 2949200-add-repository-checkout-hook
    Issue #2949200: Adds a watchdog if removal fails, uses the reponame...

  • 71803b1 committed on 2949200-add-repository-checkout-hook
    Issue #2949200: renames hook to repo_changes
    

  • e4cd440 committed on 2949200-add-repository-checkout-hook
    Issue #2949200: sets the cgit_url_name
    

  • 738e112 committed on 2949200-add-repository-checkout-hook
    Issue #2949200: alters the cgit_url to come from the repository on disk
    

  • e45eb1f committed on 2949200-add-repository-checkout-hook
    Issue #2949200: better regex that matches one elsewhere. Less code too
    

  • 730aa99 committed on 7.x-3.x
    Issue #2949200: alters the cgit_url to come from the repository on disk
    
  • 8343840 committed on 7.x-3.x
    Issue #2949200: Adds a watchdog if removal fails, uses the reponame...
  • 87042ac committed on 7.x-3.x
    Issue #2949200: better regex that matches one elsewhere. Less code too
    
  • 9a9d5b4 committed on 7.x-3.x
    Issue #2949200: sets the cgit_url_name
    
  • dc37c70 committed on 7.x-3.x
    Issue #2949200: Checks out a repository and passes it to a hook so that...
  • e0ca463 committed on 7.x-3.x
    Issue #2949200: removed some cruft
    
  • ee25bda committed on 7.x-3.x
    Issue #2949200: renames hook to repo_changes
    
Mixologic’s picture

Status: Active » Fixed

This has been deployed.

markhalliwell’s picture

I'm confused... did this actually create a drupalorg_repository_investigator module? It seems all the above commits just changed drupalorg_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.

Mixologic’s picture

The 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.

markhalliwell’s picture

Title: Create drupalorg_repository_investigator module » Add drupalorg_versioncontrol_repo_changes hook

Sure that makes sense, just double checking is all. Changing title to reflect what was actually done and for clarity/posterity sake.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.