Clarify instructions in scripts/databases

[batigolix]

I'm trying to understand the instructions in scripts/database/README.md.

What is the purpose of these steps? Should I create my own image at quay.io?

The readme says "Create a database dump of the database and save it to scripts/database/dumps/drupal8.sql. This is clear.

"This implementation uses a public Docker registry at Quay.io." Which implementation?

"Here is how to build and push a new image for the first time:" Do I need to execute these steps? Shouldnt I give the image a unique name?

[juampynr]

Hi @batigolix! Here are my answers:

What is the purpose of these steps? This is an optional step that some of us at Lullabot started doing to speed up builds and skipping the need to host a database dump somewhere.

Should I create my own image at quay.io? It's up to you. You can replace this by simply adding a command in your CI file that downloads and imports a database dump. As for where to host it, I like quay.io because it offered Robot accounts, which lets you create a token so you don't have to inject your personal password into the CI script. Docker Hub does not have this feature. There are alternatives to Quay.io though: both GitHub Packages and GitLab Container Registry can host Docker images along with the repository and have various authentication methods.

The readme says "Create a database dump of the database and save it to scripts/database/dumps/drupal8.sql. This is clear.

Yes, this is so the Dockerfile located at scripts/database can pick the database up when you run it.

"This implementation uses a public Docker registry at Quay.io." Which implementation?

I meant the example that you were reading. I changed "implementation" by "example" in case it makes it clearer. If not, please let me know how could I make it clearer.

"Here is how to build and push a new image for the first time:" Do I need to execute these steps? Shouldnt I give the image a unique name?

I am not following here. Can you elaborate a bit further?

In case it helps, I wrote an article about this example at https://www.lullabot.com/articles/rocket-ship-fast-jobs-circleci-preinstalling-database.

Thanks for your feedback!

[batigolix]

Hi,

Thanks for the quick response. I have read the article at lullabot.com and this makes things a bit clearer.

Do I need to execute these steps? Shouldn't I give the image a unique name?

What is mean with this is the following: if I use quay.io then I should push the docker image to something like quay.io/batigolix/my-db-image. Correct?

The readme says to run the following commands:

cd scripts-database docker login quay.io docker build --tag quay.io/juampynr/drupal8-github-actions:latest docker push quay.io/juampynr/drupal8-github-actions:latest

It would be clearer if this was mentioned explicitly that I need to give the image a unique name and location. For example:

If you use quay.io this is how to build and push a new image for the first time:

cd scripts-database
docker login quay.io
docker build --tag quay.io/juampynr/drupal8-github-actions:latest
docker push quay.io/juampynr/drupal8-github-actions:latest

You should replace juampynr/drupal8-github-actions with your account name and image name.

I think it is confusing for me as I am not familiar with creating and hosting docker images.

[salvamomo]

@batigolix note that the main benefit of hosting a docker image in an image registry will come only if the database is too big. CircleCI is a quite slow in regards to syncing files on it, but for small DBs you'll probably benefit more of having a simple workflow and simply download the DB from another place, or run a site install to generate a clean DB directly in Circle.

If you don't need your actual populated DB for any of your Circle jobs, I'd recommend not bothering hosting the db in an external image.

[juampynr]

What is mean with this is the following: if I use quay.io then I should push the docker image to something like quay.io/batigolix/my-db-image. Correct?

Correct!

As for the suggestion to make the docker build and push clearer. I just added that line. Thanks @batigolix !

https://github.com/Lullabot/drupal8ci/commit/039ed5d68de2d0f8c8b182b44607a969eee298a3

[batigolix]

Thanks both.

@salvamomo : I would like to figure out if I can run behat tests against a realistic database during a Github Actions job.

I will check if it is feasible to download and import a database in a Github Actions jobs.

[salvamomo]

Sounds good! In my experience Github Actions environments are way faster than Circle ones, in regards to I/O operations on the filesystem, so there wasn't much point on using a registry only for those jobs, given the speed gains were not very noticeable.

If you end up going with images, note Github also has an image registry and works very well, so you wouldn't "need" to use quay's.

[fjgarlin]

Regarding the topic of the database, the implementation has changed a bit in the last iterations of the project (mostly here https://github.com/Lullabot/drupal9ci/pull/70 with updated readme).

In order to run Behat or CypressIO tests, the easiest way would be to place a "recent" copy of the DB somewhere accessible where only your systems know the URL and then set it as environment variable DB_DUMP_URL in any of the CI systems. This should work out of the box.

If you have aliases (drush sa) set up in the repo and can access copies of some environments, you could add drush sql-sync @source @destination as part of the building jobs (changing the Robofile.php mostly). For example: drush sql-sync @live default to get the latest database from the live system. If credentials are needed to achieve this or ssh keys or similar you could put them as environment variables too.

[juampynr]

Closing as the docker database image is not used any more as the examples download and install a database dump.