documentation/feisty_meow_command_reference.txt

   1
   2 Welcome, adventurous script user.
   3
   4 These are the handiest commands available in the Feisty Meow scripts.
   5 Note that each script is expected to be self-documenting.  Try running it
   6 with a "--help" flag (or with no parameters in some cases) to print the
   7 built-in docs.  At worst, you may have to read the script (documentation
   8 fail--please let us know).
   9
  10 setup and loading commands
  11 ==========================
  12
  13 + read "readme.txt" in the top of the feisty meow codebase, or
  14 + read it online at: https://feistymeow.org/feisty_meow/readme.txt
  15
  16 revision control commands
  17 =========================
  18
  19 all revision control commands bring up the editor in the EDITOR environment
  20 variable when creating commit messages.  you need to actually save and quit
  21 from that editor when you're done writing your commit message.
  22
  23   here's a guide to writing good commit messages:
  24   + https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
  25
  26 ========
  27 the first suite of commands takes a list of directory names as parameters and
  28 then operates on those names.
  29 ========
  30
  31   rgetem:
  32   does a simple update (or pull) of the repository paths provided on the
  33   command line.  this will only get things from the main origin that the
  34   repository is hooked up with, so it is super quick compared to the next
  35   couple commands.
  36
  37   rpuffer:
  38   update the repositories provided on the command line by "puffing them out",
  39   which means that the upstream repositories that feed the local one will be
  40   synched up with it.  this is quite important to do when a git repository has
  41   multiple branches, since unmerged changes upstream can really snarl up your
  42   checkin.  this is basically a heavyweight version of rgetem.
  43
  44   rcheckin:
  45   checks in the list of repositories passed on the command line.  in git
  46   parlance, this adds all modified or untracked files, then commits all
  47   changes in the repository, and finally pushes up the changes to the remote
  48   online repository.  before doing the checkin, this will do a full "rpuffer"
  49   update on the repository to ensure that there are no unmerged upstream
  50   changes that could cause problems later.
  51
  52 ========
  53 the next suite of commands uses the REPOSITORY_LIST environment variable as
  54 the set of revision controlled folders to operate on.  the feisty meow scripts
  55 automatically add the feisty meow top-level (the apex) to this list to ensure
  56 that updates are received when available.
  57 ========
  58
  59   getem:
  60   update all repositories in the REPOSITORY_LIST from their upstream remote
  61   counterparts.  fast.
  62
  63   puffer:
  64   puffs out the REPOSITORY_LIST items to merge upstream changes.
  65
  66   checkin:
  67   checks in all changes in the REPOSITORY_LIST to their remote repositories.
  68
  69 ========
  70 some assorted other revision control commands:
  71 ========
  72
  73   feisty_branch:
  74   shows the current branch that is checked out.
  75
  76   this command will move your feisty meow codebase to the development branch:
  77   pushd $FEISTY_MEOW_APEX; git checkout dev; popd
  78
  79   and this command will get you back onto the mainline branch:
  80   pushd $FEISTY_MEOW_APEX; git checkout master; popd
  81
  82 =============================
  83 the site avenger script suite
  84 =============================
  85
  86 the site avenger tools (inherited from the avbash project) are commands for
  87 managing web sites.  these scripts offer a lot of power to the developer, and
  88 of course that comes with great responsibility...
  89
  90 the site avenger scripts are configured by "app" files stored in the "config"
  91 directory (in $FEISTY_MEOW_SCRIPTS/scripts/site_avenger/config).  the scripts
  92 seek out a config file named after the application, e.g. they look for
  93 "winterportlibrary.app" if the application name is "winterportlibrary".
  94 the basic config file "default.app" is used for any application that is unknown
  95 in the config directory.  any of the variable definitions provided in
  96 default.app can be overridden to change how the applications, and associated
  97 web site and domain, are configured.  see "mapsdemo.app" for an example of
  98 overriding the domain name for the mapsdemo application.
  99
 100   revamp_cakelampvm:
 101   establishes permissions and ownership to make the virtual machine and its
 102   services behave properly.  if something goes wonky, try running this script.
 103   this script is also the main vehicle for delivering configuration changes
 104   to the cakelampvm.  we are trying really hard to never release a version 2
 105   of the vm, since we can patch it as needed using the revamp script.  let's
 106   see how well that works out...
 107
 108   standup:
 109   brings up an application or web site from scratch (potentially) by creating
 110   an appropriate domain name, writing a basic apache site config file, pulling
 111   the application from a git repository, and "powering up" the application via
 112   composer.  this is most powerful and effective on php sites, but can also be
 113   used for other types of websites.  note that this, and all of the scripts
 114   here, are heavily biased for site avenger based development at saco designs.
 115   to make these scripts truly your own, write configuration files (see above)
 116   that define the proper folders and repository for your applications.
 117
 118   teardown:
 119   takes down a site previously brought up by the standup command.  this just
 120   eliminates the domain and the apache site though; the code is left in place
 121   to prevent disaster.
 122
 123   powerup:
 124   similar to standup, but just gets the application source out and powers it
 125   up with composer.
 126 (note: automatic database configuration and inflation is in the pipeline but
 127 is not ready yet.  that will go into powerup.)
 128
 129   avcoreup:
 130   updates the avcore portion of a site avenger application.  this command can
 131   accept an application name within which to update, or it can auto-pick the
 132   applicatin for you from the available checked out ones in ~/apps (the default
 133   storage folder for all site avenger style sites).
 134
 135   siteup:
 136   updates the entire checked out repository for a site avenger application.
 137   supports app name on the command line, or auto-picks the app.
 138
 139   sitepush:
 140   checks in the source code and other site assets for a site avenger app.
 141   supports passing an app name on the command line, or auto-picks the app.
 142
 143
 144   satis-refresh:
 145   updates satis for a site(?).
 146 note: this is the one site avenger command that hasn't been "feisty meowicized" yet.
 147
 148 lower level scripts used by site avenger scripts:
 149
 150   add_domain / remove_domain: (from system script collection)
 151   adds a DNS domain to the bind9 configuration.
 152   (the domain tools, for example, are
 153     very sensitive to edits within the chunks of code they have written.  if you
 154   need to edit bind config files, be sure to do it way above or way below the
 155   auto-generated domains.)
 156
 157   add_apache_site / remove_apache_site:
 158