[DOCS] difference between REPOSITORY and ISLANDORA_REPOSITORY

[rosiel]

I'm trying to test a buildkit PR using the site template. I'm aware that by changing one or both of REPOSITORY and ISLANDORA REPOSITORY I can make it use the boxes I just built. The description makes it very hard to tell which one to change.

With a little more context and perhaps some examples I think we could improve the .env file's internal documentation.

[nigelgbanks]

For your use case, you only have to change ISLANDORA_TAG to local if you are building the isle-buildkit images locally.

[nigelgbanks]

If you want to use the images in the pull request, you would set ISLANDORA_TAG to be the name of the branch since branches on the isle-buildkit repository are built automatically.

So for example:

The pull request:
Islandora-Devops/isle-buildkit#284

Uses the branch:
https://github.com/Islandora-Devops/isle-buildkit/tree/matomo-upgrade-4151

So we can just reference the images produced automatically without the need to build locally:
https://hub.docker.com/layers/islandora/base/matomo-upgrade-4151/images/sha256-21cf898470a3176c1c9263af61bba513ac219343fa3be58311db009f2d2a55fe?context=explore

[rosiel]

OK, if I understand it correctly, "You can easily test a PR on the isle_buildkit repository so long as the PR was made as a feature branch on the Islandora-Devops/isle-buildkit repository, by changing the ISLANDORA_TAG value from main to the name of the feature branch."

The elements of documentation which I believe are still missing are:

1 - If I need to make changes to buildkit and want to test that they work locally before making a PR (good practice) how do I do that? Do I really need to push a feature branch to the Islandora-Devlops/isle-buildkit repository?
2 - If this applies to the non-Drupal images, then what about the Drupal image? I am aware that the site template, during its build step, takes a base "Islandora Drupal image" and then does some provisioning to it, installing Drupal etc. I also understand that the right way to use this in production is to "bake" everything into a Drupal image and use that instead. How, in terms of .env variables, does that work?

[nigelgbanks]

1 - If I need to make changes to buildkit and want to test that they work locally before making a PR (good practice) how do I do that? Do I really need to push a feature branch to the Islandora-Devlops/isle-buildkit repository?

There is a way to do this within the isle-buildkit repo:

https://github.com/Islandora-Devops/isle-buildkit#running

No need to do anything with this site template to test isle-buildkit.

It's worth noting, there is also a test image in buildkit that uses the starter site. You may want to update the version of the starter site though when testing:

https://github.com/Islandora-Devops/isle-buildkit/blob/8022d93ac30c1779722c2e618334157e6a4167b9/test/Dockerfile#L4-L8

Updates to it can be submitted with the pull request you make to isle-buildkit when ready.

2 - If this applies to the non-Drupal images, then what about the Drupal image? I am aware that the site template, during its build step, takes a base "Islandora Drupal image" and then does some provisioning to it, installing Drupal etc. I also understand that the right way to use this in production is to "bake" everything into a Drupal image and use that instead. How, in terms of .env variables, does that work?

I'm not sure, I fully understand the rest of the question.

I also understand that the right way to use this in production is to "bake" everything into a Drupal image and use that instead.

This is correct, it's worth noting the dev image does the same, but we just bind-mount into the container for development convenience. The production image is the same as the dev image, it just doesn't bind-mount folders into the container.

How, in terms of .env variables, does that work?

The .env only affects the docker-compose file, replacing the variables inside of it. There are two sets of variables for source images.

• Those produced by isle-buildkit i.e. ISLANDORA_REPOSITORY and ISLANDORA_TAG.
• Those produced by this repository and are expected to be managed by the institution that clones this repository. REPOSITORY and TAG.

There is no default remote docker image repository for the images produced by this repository, as that is the responsibility of the institution that clones this repository. If they choose to set up one at all.

[nigelgbanks]

Closing due to lack of activity.