-
Notifications
You must be signed in to change notification settings - Fork 61
MAKE build Commands
⭐ These breakdowns are subject to change. These are accurate as of March 16, 2023. ⭐
MAKE commands | Description |
---|---|
demo | Make a local site from the install-profile and TODO then add demo content |
local | Make a local site with codebase directory bind mounted, modeled after sandbox.islandora.ca |
up | Brings up the containers or builds demo if no containers were found. |
starter | Make a local site with codebase directory bind mounted, using starter site. |
starter_dev | Make a local site with codebase directory bind mounted, using cloned starter site. |
✍ Note Note that some of these simply build upon another command.
make demo
❗ This one is likely to soon change to the equivalent of starter_dev
. The community is moving away from defaults and install profiles (previous methods of deploying Islandora 2.x).
This is intended to "get your feet wet" with Islandora with a look and feel of the Sandbox Site (http://sandbox.islandora.ca) including the demo content. This is both a learning tool and a tool used to test Islandora core code.
- Runs
make local
- Runs
make demo_content
- Runs a command that displays a URL to set the admin password in the UI.
make local
This is mostly intended for developing with existing codebase directories or to build one with the install profile and include a bind mount for the files. As it says in the documentation there are 2 .env settings ideal for this option.
- local - For development environments where you need edit the codebase
- custom - For production environments where your codebase gets baked into a custom container
- Downloads the defaults certs
- Generates the docker-compose.yml file
- Fetches the docker images specified in the docker-compose.yml file using the container image release tag set in the
.env
file - Creates the
codebase/
directory if it doesn't exist. - Clones it down from github.com/islandora-devops/islandora-sandbox
- Sets the file permissions needed for Drupal to run for the codebase directory.
- Starts the containers
- Run
composer install
from within the Drupal container. - Updates the settings.php file
- Installs the Islandora Install profile (islandora_install_profile_demo).
- Installs the Migrate tools
- Hydrate the site. See "Hydrate" below.
- Creates the directory for the configs to be exporter/imported (/var/www/drupal/config/sync) and sets the permissions.
- Creates the Home page from demo-data/homepage.json
- Sets a page for browse-collections/ in the same manner.
- Runs a command that displays a URL to set the admin password in the UI.
make up
❗ This one will soon change to the equivalent of starter_dev
. The community is moving away from defaults and install profiles (previous methods of deploying Islandora 2.x).
This is intended to simplify the process for "getting your feet wet" and/or to standardize the "up" process in the same manner as docker-composer up
does. As the community switched from one suggested method of building to the next, so does the "up" command. "up" should always point to the community's suggested build process. ❌ Although it currently doesn't.
- If the
docker-compose.yml
exists it starts the containers else it runs themake demo
command. - Updates the settings.php file.
- The rechecks "secrets" via the "secrets script". See below.
make starter
This is intended to be ran once to build the site and generate a codebase directory. Afterwards, you can either run make up
to start the containers or make a custom.Makefile to start it. See How to fork and use isle-dc for your institution for more information on the custom.Makefile. Part of the installation includes an optional starter theme and some starter-kit logic.
- Downloads the defaults certs
- Generates the docker-compose.yml file
- Fetches the docker images specified in the docker-compose.yml file using the container image release tag set in the
.env
file - Creates the
codebase/
directory if it doesn't exist. - Run a command to create a new Drupal site in the
codebase/
directory. (composer create-project islandora/islandora-starter-site:dev-main
) - Sets the file permissions needed for Drupal to run for the codebase directory.
- Starts the containers
- Updates the settings.php file
- Hydrate the site. See "Hydrate" below.
- Migrate the FITS tags into the site (
drush migrate:import islandora_fits_tags
) - Runs a command that displays a URL to set the admin password in the UI.
make starter_dev
This is intended to build using an existing codebase and bind mounts the codebase directory.
- Downloads the defaults certs
- Generates the docker-compose.yml file
- Fetches the docker images specified in the docker-compose.yml file using the container image release tag set in the
.env
file - Uses the existing codebase/ directory if it exists otherwise it clones github.com/Islandora-Devops/islandora-starter-site
- Sets the file permissions needed for Drupal to run for the codebase directory.
- Starts the containers
- Run
composer install
from within the Drupal container. - Updates the settings.php file
- Hydrate the site. See "Hydrate" below.
- Migrate the FITS tags into the site (
drush migrate:import islandora_fits_tags
) - Runs a command that displays a URL to set the admin password in the UI.
Hydrating a Drupal docker container refers to the process of initializing the container with the necessary data and settings to run a Drupal site. This typically involves:
Setting up the database: The container needs to be configured to connect to a database, either by using an existing database or by creating a new one.
Copying Drupal files: The container needs to have the necessary Drupal files, including the core code and any custom modules, themes, or libraries.
Configuring Drupal settings: The container needs to be configured with the necessary settings to run a Drupal site, including site name, site email, default language, and other site-specific settings.
Importing data: If you're migrating an existing Drupal site to a container, you may need to import the existing data into the container.
Hydrating a Drupal docker container is typically done when creating a new container or when updating an existing container with new data or settings. This ensures that the container is properly configured and ready to run a Drupal site.
Several of the microservices need passwords (db passwords, UI login passwords, root passwords, etc.).
- If not empty, then it checks if any of the passwords specified in the
secrets/live/
directory match any of the defaults found in thesecrets/template/
directory and warns to update before deploying to a production environment. - Or if there are missing passwords or if the
secrets/live/
directory is empty, it will prompt the user as seen in this image. - This will run every time you build the site or restart it.
To Do