App integration with repos

[stuartpb]

The latest thinking in #5 and plushu/plushu-git#9 has involved apps being created whenever a repo is created.

However, I think that's a faulty assumption - maybe we want to create repos without apps attached (or apps without repos, if we're somehow using some other kind of mechanism for apps' code). Maybe the creation of a repo alongside an app should be made into a plugin, with the reverse (creating apps whenever a repo gets created) also being a plugin (not sure if they should be the same plugin).

The real thing that needs to get fixed is the assumption between plushu-git-apps and plushu-buildstep, that receiving a push to a repo should start a build, and that a build should create an app.

(Actually, building doesn't really create an app, it just sort of implicitly/coincidentally does it because it creates the directory hierarchy to the cache directory, which includes creating the app directory, which is all that happens in Plusku when create-app gets plushooked.)

Instead, receiving needs to check for the existence of an app attached to a repo before trying to build it, and buildstep (for safety reasons / to match the freedom around the receive and deploy steps) needs to institute the same check.

The only way an app should be created is via create-app getting plushooked.

[stuartpb]

So yeah, count me in for plushu-create-apps-with-repos and plushu-create-repos-with-apps (maybe with shorter names).

[stuartpb]

While we're on the subject of close app/repo coupling, the structure of PLUSHU_REPOS_DIR has to match PLUSHU_APPS_DIR, as this is the mechanism by which apps and repos mirror each other. This... might cause trouble in certain scenarios (specifically involving super-plugins that only partially obscure other plugin contexts), and should maybe be reconsidered. Probably deserves at least a little more thought when I'm not so tired.

[stuartpb]

Perhaps plushu-create-app-repos (creates repos when creating an app) and plushu-create-repo-apps (creates an app when creating repos).

[stuartpb]

Actually, wouldn't these integration plugins also be handling linked moving, copying, and deleting? So maybe they should just be plushu-app-repos and plushu-repo-apps. (And, again, maybe they shouldn't be separate plugins.)

[stuartpb]

Yeah, I'm really leaning towards making this one bi-directional plugin.

Although I guess I could see a scenario where I don't want deleting an app attached to a repo to delete the repo - like, a scenario where repos are the primary focus, and apps are optional things you can add or remove to them...

Ehh, I think that would merit its own forked version of this plugin (since you pretty much only want one less hook - repos would still want to move with apps, and vice versa - and the copying of an app with a repo copy would be a question for the implementation, and letting each of these be separate would mean eight separate plugins that you'd probably manage with a meta-plugin anyway).

[stuartpb]

On the other hand, it's kind of a meta-plugin thing anyway, so maybe each of these would be its own plugin:

• plushu-create-app-repos (create-repo-with-app)
• plushu-create-repo-apps (create-app-with-repo)
• plushu-fork-app-copy-repo (copy-app-repos or copy-repo-on-fork-app)
• plushu-copy-repo-fork-app (copy-repo-apps or fork-app-on-copy-repo)
• plushu-rename-app-repos (rename-repo-with-app)
• plushu-rename-repo-apps (rename-app-with-repo)
• plushu-delete-app-repos (delete-repo-with-app)
• plushu-delete-repo-apps (delete-app-with-repo)

The copy ones could even have linking variants (so one repo updates two apps) or something like that. (I think in that case you'd have to track the linked instances of the repo externally, for git-update-hook, and it would probably be a separate plushook anyway. But eh, it's conceivable.)

[stuartpb]

Also, note that apps-creating-repos needs to be taken out of this plugin (apps:create &c calling out to create-repo). (Done in 2392c53.)

[stuartpb]

Honestly, the naming headache alone is enough to make me want to make this into one app-repo-binding plugin.

[stuartpb]

Wait, crap, how do you prevent these from creating an infinite loop (the rename-repo triggering a rename-app, which in turn creates another rename-repo)? I think that's why this needs to be one plugin (where each entry point runs the delegation plushook with an environment variable semaphore that says "don't recurse").

Alternately, you could go back to the repos-on-top scenario where all app behaviors are triggered by repo behaviors (I think that's why I originally wanted to model it that way). However, that means baking an assumption into the apps model, and, yes, it means you can't have a system with repos by themselves. So I think that's a worse solution than the semaphore approach.

[stuartpb]

I'd say that takes care of that.