TODO

   1 The Git Autoinstaller
   2
   3 TODO NOW:
   4
   5 - For the long running programs, I definitely want to use logging.
   6 - Whiteboard the flow for performing an upgrade on a single
   7   install. How assisted does it need to be?
   8 - Conduct migration tool testing
   9 - Create mass-migration tool (should be able to limit on mediawiki)
  10 - Run parallel-find.pl
  11 - Migrate all mediawikis
  12 - Wordpress needs to have a .scripts/update script written for
  13   its latest version
  14
  15 NOTES:
  16
  17 - A perfectly formed autoinstall with upgrade paths for all of
  18   the intervening versions is not really feasible to implement.
  19   As such, we want to migrate everything to -scripts, and then
  20   generate a -scripts2 with the correct .scripts directory.
  21   We will then nop update some installs, but this will prevent
  22   us from having to migrate and update concurrently.
  23
  24 - summary and info are still not using loggers. Maybe they should,
  25   maybe they shouldn't
  26
  27 OVERALL PLAN:
  28
  29 * Some parts of the infrastructure will not be touched, although I plan
  30   on documenting them.  Specifically, we will be keeping:
  31
  32     - parallel-find.pl, and the resulting
  33 /mit/scripts/sec-tools/store/scriptslist
  34
  35     - The current install scripts will be kept in place, sans changes
  36       necessary to make them use Git install of copying the script over.
  37       Porting these scripts to Python and making them modular would be
  38       nice, but is priority.  For the long term, seeing this scripts
  39       be packaged with rest of our code would be optimal.
  40
  41 * The new procedure for generating an update is as follows (this is
  42   also similar to procedure for creating these repositories):
  43
  44     1. Have the Git repository and working copy for the project on hand.
  45
  46     2. Checkout the pristine branch
  47
  48     3. Remove all files from the working copy (rm -Rf *, and then delete
  49        any dot stragglers.  A script to do this would be handy)
  50
  51     4. Download the new tarball
  52
  53     5. Extract the tarball over the working copy (`cp -R a/. b` works well,
  54        remember that the working copy is empty)
  55
  56     6. Check for empty directories and add stub files as necessary
  57        (use preserve-empty-dir)
  58
  59     7. Git add it all, and then commit as a new pristine version (v1.2.3)
  60
  61     8. Checkout the master branch
  62
  63     9. [FOR EXISTING REPOSITORIES]
  64        Merge the pristine branch in. Resolve any conflicts that our
  65        patches have with new changes. Do NOT let Git auto-commit it
  66        with --no-commit (otherwise, you want to git commit --amend
  67        to keep our history clean
  68
  69        [FOR THE FIRST TIME]
  70        Apply the scripts patch that was used for that version here
  71        (usually patch -p1 < patch)
  72
  73    10. Check if there are any special update procedures, and update the
  74        .scripts/update shell script as necessary (this means that any
  75        application specific update logic will be kept with the actual
  76        source code.  The language of this update script will vary
  77        depending on context.)
  78
  79    11. Commit your changes, and tag as v1.2.3-scripts
  80
  81    If you're setting up a repository from scratch, stop here, and
  82    repeat as necessary
  83
  84        XXX: Should we force people to push to the real repository at
  85        this point, or just make the repository that the script pulls
  86        stuff out of configurable? (Twiddling origin can get you a
  87        devel setup with no code changes)
  88
  89    12. Run the "dry-run script", which uses Git commands to check how many
  90        working copies apply the change cleanly, and writes out a logfile
  91        with the working copies that don't apply cleanly.
  92
  93    13. Run the "limited run" script, which applies the update to our
  94        test-bed, and lets us check the basic functionality of the update.
  95        This can include a script that lets us update a single directory
  96        with verbose output.
  97
  98    14. Run the "deploy" script, which applies the update to all working
  99        copies possible, and sends mail to users to whom the working copy
 100        did not apply cleanly. It also frobs .scripts/version for successful
 101        upgrades.
 102
 103    15. Run parallel-find.pl
 104
 105 * For mass importing into the repository, the steps are:
 106
 107 [TO SET IT UP]
 108 # let app-1.2.3 be the scripts folder originally in deploydev
 109 # let this folder be srv/
 110 # you can also do a git clone
 111     mkdir app
 112     cd app
 113     git init
 114     cd ..
 115 unfurl app-1.2.3 app
 116 # NOTE: contents of application are now in app directory
 117 cd app
 118 git add .
 119 git commit -s -m "App 1.2.3"
 120 git tag v1.2.3
 121 git branch pristine
 122 # NOTE: you're still on master branch
 123 # WARNING: the following operation might require -p1
 124 patch -p0 < ../app-1.2.3/app-1.2.3.patch
 125 # NOTE: please sanity check the patch!
 126 git add .
 127 # NOTE: -a flag is to handle if the patch deleted something
 128 git commit -as -m "App 1.2.3-scripts"
 129 git tag v1.2.3-scripts
 130
 131 [TO ADD AN UPDATE]
 132 # let this folder be srv/app.git
 133 git checkout pristine
 134 # NOTE: this preserves your .git folder, but removes everything
 135 wipe-working-dir .
 136 cd ..
 137 unfurl app-1.2.3 app
 138 cd app
 139 # NOTE: please sanity check app directory
 140 git add .
 141 # NOTE: -a is to take care of deletions
 142 git commit -as -m "App 1.2.3"
 143 git tag v1.2.3
 144 [IF THE PATCH HAS CHANGED]
 145     # You are on the pristine branch
 146     # NOTE: Now, the tricky part (this is different from a real update)
 147     git symbolic-ref HEAD refs/heads/master
 148     # NOTE: Now, we think we're on the master branch, but we have
 149     # pristine copy checked out
 150     # NOTE: -p0 might need to be twiddled
 151     patch -p0 < ../app-1.2.3/app-1.2.3.patch
 152     git add .
 153     # COMMENT: used to git checkout .scripts here
 154     # then check if the directory needs an updated update script
 155     # NOTE: Fake the merge
 156     git rev-parse pristine > .git/MERGE_HEAD
 157 [IF THE PATCH HASN'T CHANGED]
 158     git checkout master
 159     git merge --no-commit pristine
 160 git commit -as -m "App 1.2.3-scripts"
 161 git tag v1.2.3-scripts
 162
 163
 164 * The repository for a given application will contain the following files:
 165
 166     - The actual application's files, as from the official tarball
 167
 168     - A .scripts directory, which contains the following information:
 169
 170         [IF THIS IS THE FIRST UPDATE]
 171             mkdir .scripts
 172             echo "Deny from all" > .scripts/.htaccess
 173             touch .scripts/update
 174             chmod a+x .scripts/update
 175             # OPERATION: create the update script
 176
 177         * .scripts/update shell script (with the +x bit set appropriately),
 178           which performs the commands necessary to update a script.  This can
 179           be in any language.
 180
 181         * .scripts/.htaccess to prevent this directory from being accessed
 182           from the web.
 183
 184         * .scripts/database (generated) contains the database the
 185           user installed the script to, so scripts-remove can clean it
 186
 187             XXX: Could cause problems if a user copies the autoinstall,
 188             fiddles with the DB credentials, and then scripts-remove's
 189             the autoinstall.  Possible fix is to add the original
 190             directory as a sanity check.  Additionally, we could have
 191             the application read out of this file.
 192
 193         * .scripts/version (generated) which contains the version
 194           last autoinstalled (as distinct from the actual version
 195           the script is) (This is the same as .scripts-version right
 196           now; probably want to keep that for now)
 197
 198             XXX: It's unclear if we want to move to this wholesale, or
 199             delay this indefinitely.
 200
 201 * The migration process has been implemented, see 'wizard migrate'.
 202
 203     XXX: We have not decided what migration should do to .scripts-version;
 204     if it does move it to .scripts, repositories should have a .gitignore
 205     in those directories
 206
 207 * The autoupgrade shall be the process of:
 208
 209     # Make the directory not accessible by the outside world (htaccess, but be careful!)
 210     git add -u .
 211     git commit -m 'automatically generated backup'
 212     git pull origin master
 213     if [ $? ne 0 ]; then git reset --hard; echo 'conflicts during upgrade'; fi
 214     ./.scripts/update
 215     # Make it accessible
 216
 217   (with some more robust error checking)
 218
 219 * Make 'wizard summary' generate nice pretty graphs of installs by date
 220   (more histograms, will need to check actual .scripts-version files.)