I migrated Digital.Grinnell to ISLE back in December 2018, and did so largely by following the documented migration path (although there was more than one documented path at the time). The migration was not 100% effective since that process brought along all the old modules, and subsequently the bugs, present in the old DG.
In January 2019 I went to work trying to create a local/dev instance of ISLE that exactly matches my production version, but constructed in a manner that would allow me to build it up "from scratch" where possible, and successfully engage XDebug and PHPStorm, in my case, when complete. That process involved this project, ISLE-Drupal-Build-Tools, and I quickly found that the tools were easy to implement, but not so easy to change in a maintainable manner. Specifically, the intended but largely undocumented approach was to clone this repo, create a new 'custom' copy of the isle_islandora_installer.sh script, make changes to that copy, and launch the script to build a new local/dev of ISLE. While that approach worked, I worried that it would be difficult or even impossible to sustain across many institutions.
I set out then to refactor ISLE-Drupal-Build-Tools with these goals in mind:
Create a system that does not require a customized "copy" of the main script. Instead, create a script that looks for customization as "additions" only, and invokes the additions if/when they exist. The approach is not unlike adding implementations of hook functions in Drupal.
Enable provisioning of XDebug and PHPStorm for debugging in the local/dev instance of ISLE.
Produce more readable output from the process. There's a lot of output so I thought a little more organization was in order.
Begin the process of documenting how the tools work and how to use them properly.
Implement and document a process for capturing a small, portable Fedora repository on a USB stick or similar device.
I would like to encourage others in the ISLE development community to examine my work and take it for a spin if possible. I'd love to see how it plays in your environment and welcome additions and changes where necessary. And more/better documentation is still needed.
I migrated Digital.Grinnell to ISLE back in December 2018, and did so largely by following the documented migration path (although there was more than one documented path at the time). The migration was not 100% effective since that process brought along all the old modules, and subsequently the bugs, present in the old DG.
In January 2019 I went to work trying to create a local/dev instance of ISLE that exactly matches my production version, but constructed in a manner that would allow me to build it up "from scratch" where possible, and successfully engage XDebug and PHPStorm, in my case, when complete. That process involved this project, ISLE-Drupal-Build-Tools, and I quickly found that the tools were easy to implement, but not so easy to change in a maintainable manner. Specifically, the intended but largely undocumented approach was to clone this repo, create a new 'custom' copy of the
isle_islandora_installer.shscript, make changes to that copy, and launch the script to build a new local/dev of ISLE. While that approach worked, I worried that it would be difficult or even impossible to sustain across many institutions.I set out then to refactor ISLE-Drupal-Build-Tools with these goals in mind:
I won't go into a lot of detail here, but will leave this thread open with pointers to the work I've done thus far. You can find it in https://github.com/DigitalGrinnell/ISLE-Drupal-Build-Tools/tree/Digital.Grinnell, the
Digital.Grinnellbranch of the project fork I created in January. To complement the refactored build I also made changes to ISLE and you'll find those in https://github.com/DigitalGrinnell/ISLE/tree/isle-ld, theidle-ldbranch of an ISLE fork I created early on.I would like to encourage others in the ISLE development community to examine my work and take it for a spin if possible. I'd love to see how it plays in your environment and welcome additions and changes where necessary. And more/better documentation is still needed.