Closed stuartpb closed 10 years ago
And the onus would be on build plugins to provide as many hooks as possible, and receivers would only call whichever one is a better fit. This makes sense: more interfaces could be added to support other mechanisms (receiving a slug via HTTP?), and if a receive plugin doesn't understand that, nothing breaks because the receive plugin calls out to one of the other hooks (that maybe transforms it into one of the other formats so the build step works the way its code needs).
I'm going with build-app-tar
since I didn't find any official use of the term "tarball" in tar's manpage, and it's not like the shorter build-app-tar
is any more ambiguous.
Right now, the tarball interface is an implicit part of
build
, which it doesn't need to be (it's just as possible the interface could be provided via, say, a directory).If we had a hook like
build-app-dir
, this plugin could provide interfaces for both, and then plushu-git-receive-app could call out to us viabuild-app-tarball
for the case wheregit archive
works andbuild-app-dir
for the submodule case where it has to clone into a subdirectory. (And, if building gets swapped out to use a host volume, the build step could then use that directory directly.)