Closed rosiel closed 3 months ago
For your use case, you only have to change ISLANDORA_TAG
to local
if you are building the isle-buildkit
images locally.
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: https://github.com/Islandora-Devops/isle-buildkit/pull/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
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?
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:
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.
isle-buildkit
i.e. ISLANDORA_REPOSITORY
and ISLANDORA_TAG
.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.
Closing due to lack of activity.
I'm trying to test a buildkit PR using the site template. I'm aware that by changing one or both of
REPOSITORY
andISLANDORA 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.