Since update-deployment is run on the host being deployed to and only
has access to a recent clone of the git repository, it doesn't
necessarily have the old refs available for reverts.
(imported from commit 3652f58a7b165c805822bf6d8a4f0792c629e28e)
This requires manual steps on deploy to each of staging and prod:
(1) Run the new update-deployment code to setup the initial deployment directory.
(2) Restart all the programs running in screen sessions.
(3) Deploy the nginx changes and restart nginx.
(imported from commit 1ffe27933ee79274dc0a93d35c9938712de0ef36)
We leave the stuff under api/ alone for now, since we need to be able to ship
it as a standalone thing.
tools/post-receive wasn't using the function anyway.
For push to master: Push this commit, update post-receive per instructions at
the top of that file, then push the rest of the branch to confirm that the hook
still works.
No manual instructions for prod.
(imported from commit 9bcbe14c08d15eda47d82f0b702bad33e217a074)
At Ksplice we used /usr/bin/python because we shipped dependencies as Debian /
Red Hat packages, which would be installed against the system Python. We were
also very careful to use only Python 2.3 features so that even old system
Python would still work.
None of that is true at Humbug. We expect users to install dependencies
themselves, so it's more likely that the Python in $PATH is correct. On OS X
in particular, it's common to have five broken Python installs and there's no
expectation that /usr/bin/python is the right one.
The files which aren't marked executable are not interesting to run as scripts,
so we just remove the line there. (In general it's common to have libraries
that can also be executed, to run test cases or whatever, but that's not the
case here.)
(imported from commit 437d4aee2c6e66601ad3334eefd50749cce2eca6)
This uses pylibmc, the same memcached client library we use from Django. If
that becomes a problem for whatever reason, all we really need to do is send
"flush_all\n" to TCP port 11211 on localhost.
(imported from commit 0b9736bd31b0549b5dabd4b735706351635a9cf2)
After this commit, we're tracking two branches: "master" and "prod".
Pushed to "prod" deploy to production, while pushes to "master" deploy
to the staging server.
(imported from commit 6ce429a1d6f606fb6136341dc393d93fd1228a21)
We need this for client auto-reload on static file changes, because the server
generation comes from get_updates.
(imported from commit c5e97421883383c12891fdcb177d0f6fda4b4857)
Will warn about schema changes based on '[schema]' appearing anywhere
in the commit message.
(imported from commit 0092f12c1a2dad3f909ec1934c162776d72263b4)
Zev Benjamin
Tim Abbott
Keegan McAllister