summary |
shortlog |
log |
commit | commitdiff |
tree
raw |
patch |
inline | side by side (from parent 1:
3c4ee77)
svn path=/trunk/scripts/git-hooks/; revision=2358
-superrepo heads are dev, prod
+superrepo heads are dev, prod, and dev-incoming, prod-incoming
+ reject commits to dev, prod
+ grab lock or fail
+ spawn build process
+ zephyr
+
+in build process for foo-incoming:
for each changed submodule revision:
(as optimization: if same commit already in dev, just reprepro move)
try to build submodule
if fail:
for each changed submodule revision:
(as optimization: if same commit already in dev, just reprepro move)
try to build submodule
if fail:
clean up any previous packages' built files, maybe keep this one's around
remember package and version
for each changed submodule revision: (if we're still going)
tag submodule with version
upload to dev/prod respectively
clean up built files
clean up any previous packages' built files, maybe keep this one's around
remember package and version
for each changed submodule revision: (if we're still going)
tag submodule with version
upload to dev/prod respectively
clean up built files
+ commit to foo
+ zephyr?
+ release lock
+if fail:
+ reset foo-incoming to old revision
+ send mail with log
-This makes a long pre-receive process. Is that cool?
-Probably is the right thing.
-
+Maybe there could be something sane without the lock? It'd require
+more thought.