docker -> dc

dc is shorter to type, and in the end these commands
are docker-compose wrappers indeed.

Author: fxn

config/initializers/ensure_rails_git_is_cloned.rb

@@ -3,15 +3,15 @@
 unless Dir.exists?(RAILS_GIT)
   puts <<~EOS
     Please, mirror the Rails repository using the command
-    
+
       git clone --mirror https://github.com/rails/rails.git
 
     from the host computer.
-    
+
     Once that is done, if you want to run the website please
     populate the database with
 
-      docker/sync
+      dc/sync
 
     This takes a while and it is not necessary if you only
     want to run the test suite.

dc/bash

@@ -0,0 +1,3 @@
+#!/bin/bash
+
+exec dc/exec bash "$@"

dc/deploy

@@ -0,0 +1,3 @@
+#!/bin/bash
+
+exec dc/exec cap production deploy

docker/exec renamed to dc/exec

@@ -0,0 +1,3 @@
+#!/bin/bash
+
+exec dc/rails db -p

dc/psql

@@ -0,0 +1,3 @@
+#!/bin/bash
+
+exec dc/exec bin/rails "$@"

dc/rails

@@ -8,5 +8,5 @@ if [[ $1 = 'staging' ]]; then
   docker-compose exec -e RAILS_SERVE_STATIC_FILES=1 app \
     bin/rails server -b 0.0.0.0 -e staging
 else
-  docker/rails server -b 0.0.0.0
+  dc/rails server -b 0.0.0.0
 fi

docker/server renamed to dc/server

@@ -6,7 +6,7 @@ if [[ ! -d rails.git ]]; then
 fi
 
 if [[ $1 = 'all' ]]; then
-  exec docker/rails runner "Repo.sync(rebuild_all: true)"
+  exec dc/rails runner "Repo.sync(rebuild_all: true)"
 else
-  exec docker/rails runner Repo.sync
+  exec dc/rails runner Repo.sync
 fi

docker/sync renamed to dc/sync

@@ -6,9 +6,9 @@ If you just cloned the project:
 
 ```
 $ docker-compose up -d
-$ docker/exec bundle install
-$ docker/rails db:setup
-$ docker/sync
+$ dc/exec bundle install
+$ dc/rails db:setup
+$ dc/sync
 ```
 
 The last command is going to clone the Rails repository and populate the database, it takes several minutes.
@@ -21,7 +21,7 @@ The application assumes `rails.git` is present in the root directory with a mirr
 git clone --mirror https://github.com/rails/rails.git
 ```
 
-That clone is performed by `docker/sync` automatically, but it does not update itself. To do so, please run
+That clone is performed by `dc/sync` automatically, but it does not update itself. To do so, please run
 
 ```
 $ cd rails.git
@@ -48,27 +48,26 @@ A number of convenience scripts are located in the `docker` directory, all of th
 
 | Command         | Description                |
 | --------------- | -------------------------- |
-| `docker/bash`   | Gets a Bash shell          |
-| `docker/psql`   | Gets a `psql` shell        |
-| `docker/rails`  | Runs `bin/rails`           |
-| `docker/server` | Launches Puma in port 3000 |
-| `docker/sync`   | Syncs the database         |
-| `docker/deploy` | Deploys the application    |
+| `dc/bash`   | Gets a Bash shell          |
+| `dc/psql`   | Gets a `psql` shell        |
+| `dc/rails`  | Runs `bin/rails`           |
+| `dc/server` | Launches Puma in port 3000 |
+| `dc/sync`   | Syncs the database         |
+| `dc/deploy` | Deploys the application    |
 
-The commands `docker/server` and `docker/psql` are convenience wrappers around `docker/rails`. In general `docker/rails` is the main command:
+The commands `dc/server` and `dc/psql` are convenience wrappers around `dc/rails`. In general `dc/rails` is the main command:
 
 ```
-$ docker/rails test
-$ docker/rails console
-$ docker/rails db:migrate
-$ docker/rails runner 'p Commit.count'
+$ dc/rails test
+$ dc/rails console
+$ dc/rails db:migrate
+$ dc/rails runner 'p Commit.count'
 $ ...
 ```
 
-The command `docker/server staging` runs the application in `staging` mode. That is a production-like environment (`config/environments/staging.rb` is a symlink to `config/environments/production.rb`), but it uses the development database and serves static files. If there are changes that act differently in `development` and `production`, this execution mode may be useful for checking things up before deployment.
+The command `dc/server staging` runs the application in `staging` mode. That is a production-like environment (`config/environments/staging.rb` is a symlink to `config/environments/production.rb`), but it uses the development database and serves static files. If there are changes that act differently in `development` and `production`, this execution mode may be useful for checking things up before deployment.
 
-If you modify the name mappings, hard-coded authors, etc., `docker/sync`
-updates the credits and it does so changing as little as possible. The command also accepts an optional argument `all`, which forces the recomputation of all assignments. This is handy when you've changed the heuristics, and it takes less than a full database rebuild, since it does not reimport the commits themselves (which is costly).
+To update the local Rails checkout and update the credits run `dc/sync`. The command also accepts an optional argument `all`, which forces the recomputation of all assignments. This is handy when you've changed the heuristics, and it takes less than a full database rebuild, since it does not reimport the commits themselves (which is costly).
 
 ## Database persistence