|
|
|
|
240
|
able to determine (and expose) what files just changed enables new
|
240
|
able to determine (and expose) what files just changed enables new
|
241
|
functionality such as plugins that cross-post to tumblr.
|
241
|
functionality such as plugins that cross-post to tumblr.
|
242
|
|
242
|
|
243
|
-Git's post-receieve hook is supposed to get a list of refs on $STDIN.
|
|
|
244
|
-A brave soul could update our post-receive script to figure out the
|
|
|
245
|
-original hash and pass that along to `coleslaw:main`. We could then
|
|
|
246
|
-use it to run `git diff --name-status $HASH HEAD` to find changed
|
|
|
247
|
-files and act accordingly.
|
|
|
|
|
243
|
+Git's post-receive hook is supposed to get a list of refs on $STDIN.
|
|
|
244
|
+A brave soul could update our post-receive script to iterate over
|
|
|
245
|
+those lines as shown in step 3 of this [blog post][post_receive_blog].
|
|
|
246
|
+There would be two primary benefits:
|
|
|
247
|
+
|
|
|
248
|
+1. We could pass the oldrev (previous revision) of the blog repo
|
|
|
249
|
+ to `coleslaw:main`. That could be used in conjunction with
|
|
|
250
|
+ `get-updated-files` to get a list of the files modified in the
|
|
|
251
|
+ last push. This would enable cross-posting plugins to be developed
|
|
|
252
|
+ as well as opening the door for incremental compilation.
|
|
|
253
|
+2. More seriously, **Coleslaw** currently deploys for _any_ branch
|
|
|
254
|
+ pushed to the bare repo. This change would also ensure that we only
|
|
|
255
|
+ invoke `coleslaw:main` when a push is made to the master branch.
|
248
|
|
256
|
|
249
|
This is a cool project and the effects are far reaching. Among other
|
257
|
This is a cool project and the effects are far reaching. Among other
|
250
|
things the existing deployment model would not work as it involves
|
258
|
things the existing deployment model would not work as it involves
|
251
|
rebuilding the entire site. In all likelihood we would want to update
|
259
|
rebuilding the entire site. In all likelihood we would want to update
|
252
|
-the site 'in-place'. Atomicity of filesystem operations would be a
|
|
|
253
|
-reasonable concern. Also, every numbered INDEX would have to be
|
|
|
254
|
-regenerated along with any tag or month indexes matching the
|
|
|
255
|
-modified files. If incremental compilation is a goal, simply
|
|
|
256
|
-disabling the indexes may be appropriate for certain users.
|
|
|
257
|
-
|
|
|
|
|
260
|
+the site 'in-place'. How to replace the compilation and deployment
|
|
|
261
|
+model via a plugin has not yet been explored. Atomicity of filesystem
|
|
|
262
|
+operations would be a reasonable concern. Also, every numbered INDEX
|
|
|
263
|
+would have to be regenerated along with any tag or month indexes
|
|
|
264
|
+matching the modified files. If incremental compilation is a goal,
|
|
|
265
|
+simply disabling the indexes may be appropriate for certain users.
|
|
|
266
|
+
|
|
|
267
|
+[post_receive_blog]: http://codeshal.tumblr.com/post/927943180/git-post-receive-hook-that-submits-code-to-review-board
|
258
|
[post_receive_hook]: https://github.com/redline6561/coleslaw/blob/master/examples/example.post-receive
|
268
|
[post_receive_hook]: https://github.com/redline6561/coleslaw/blob/master/examples/example.post-receive
|
259
|
[closure_template]: https://github.com/archimag/cl-closure-template
|
269
|
[closure_template]: https://github.com/archimag/cl-closure-template
|
260
|
[api_docs]: https://github.com/redline6561/coleslaw/blob/master/docs/plugin-api.md
|
270
|
[api_docs]: https://github.com/redline6561/coleslaw/blob/master/docs/plugin-api.md
|