cyork
commented
4 years ago Right now, the environment available for local development is birkland/idc-dev.
The defining characteristics of this are:
- It pulls in the latest ISLE, for the purpose of building a dynamically building a main docker-compose.yml each time a development environment is set up
- It contains ISLE build parameters in the form of environment variables (e.g. 'don't include Fedora the stack, and potentially custom docker-compose files
- It pulls in our latest Drupal site from git
- It involves the ISLE Makefile to "hydrate" an Islandora stack (set up solr, databases, etc) from scratch
Does this suit our needs, or do we need a different pattern?
Options include:
- maintaining our own (resulting from occasionally invoking ISLE?) docker-compose.yml file, instead of leveraging ISLE to build it
- Maintaining a fork of isle-dc, rather than pulling it in
The development team should agree on the best way forward
Expected outcome:
[ ] Make recommendation for the better approach → secure team’s agreement on it. → record decision on ticket.
I've shared a document that captures feedback for the ISLE team on what it took to integrate SimpleSAMLphp using idc-dev.
At the very least, we will need to update the framework (e.g. isle-dc's Makefile) that generates the docker-compose.yml to resolve image hashes to image tags, and I also think that the generated files (e.g. the docker-compose*yml in idc-dev/local) ought to be in version control. That way someone who is less familiar with ISLE can reason about the state of the Docker Compose runtime over time without being required to understand or work with the commit histories of isle-buildkit and isle-dc.
I think things would be marginally more transparent if isle-buildkit and isle-dc were in a single repository, but I don't think we could move forward with something like that on our own without ISLE doing that as well. The maintenance burden would be too high.