From ed68c7c97bd87134c991a9ba10eef63bc3fdaac4 Mon Sep 17 00:00:00 2001
From: Tanner Prestegard <tanner.prestegard@ligo.org>
Date: Wed, 28 Dec 2016 14:39:31 -0600
Subject: [PATCH] quick fix to admin docs
---
admin_doc/source/new_server_feature.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/admin_doc/source/new_server_feature.rst b/admin_doc/source/new_server_feature.rst
index 1ecb7aa3a..445837f93 100644
--- a/admin_doc/source/new_server_feature.rst
+++ b/admin_doc/source/new_server_feature.rst
@@ -30,7 +30,7 @@ changes to the GraceDB server codebase. Here's how I like to go about it.
WSGI script file, since the daemon monitors this file for any changes::
cd /home/gracedb/wsgi
- touch wsgi.py
+ touch django.wsgi
#. Iterate until the code is in a state that you like. If the process is
involved, you may want to make several commits along the way::
@@ -46,7 +46,7 @@ changes to the GraceDB server codebase. Here's how I like to go about it.
export TEST_SERVICE='https://gracedb-test.ligo.org/api/'
python test.py
-#. If everythingg looks good, go back to gracedb-test, merge our branch into
+#. If everything looks good, go back to gracedb-test, merge our branch into
master, and push it::
cd /home/gracedb/gracedb
@@ -64,7 +64,7 @@ changes to the GraceDB server codebase. Here's how I like to go about it.
#. As with the test machine, you'll need to touch the WSGI script as well::
- touch gracedb/wsgi/wsgi.py
+ touch gracedb/wsgi/django.wsgi
And now your new feature or bugfix should be live on the production machine.
The scenario I've outlined above is more-or-less the simplest way things can
--
GitLab