michaelmcandrew
commented
6 years ago Hi Sean,
Thanks for trying it out and feeding back with this issue - appreciated :)
Some thoughts and things I did in response.
I moved the pecl extensions to their own RUN statement after the calls to docker-php-ext. Deciding on your RUN statement granularity is an art, apparently :art:, but this seemed appropriate.
I had a quick google on the printf "\n" | syntax and it looks like a way to accept defaults. I wondered why this was necessary in 5.6 but not in 7.0. I tested it locally with 5.6 (using a seperate RUN statment) and I did not need to add the statements. In other words, you shouldn't have needed to add the printf statements. Maybe something for you to investigate a bit more if you feel like it?.
One thing that did barf for me was the xdebug version. It seems like we do need to specify a compatible version for php5 (which seems a bit sub-optimal - I wonder why it doesn't just select the most recent compatible version).
So how do we handle different versions and the different steps needed for each? I think there are two sides to this question. The Dockerfile side and the docker-compose side.
Dockerfile
If you take a look at the docker hub php page, you will see lots of options, or tags, as Docker likes to call them.
I think the Docker solution to this problem is to create various tags for the buildkit image that specify the php version that they come with, e.g. :php7 and :php5. Notice on the php image set that 5 is a shorthand for 5.6, which is a shorthand for 5.6.something.
In terms of how we produce different versions, I am fairly sure that templating is the solution. The official Docker PHP repo uses gawk and sed. Since I am not that hard-core, and we are a PHP community, I thought that Twig would be a good option. I put together a first draft automated publisher. It is a little rough and ready but fit for purpose and we can improve it as necessary.
I really like the idea of other people being able to use this project without having too much understanding of Docker.
Yeah, I agree. A basic understanding is required. I am trying to address common gotchas in the readme but not replicate Docker basics. If we can make CiviCRM more cloud native, there will be less gotchas.
Aside: There is a whole other debate about whether we should be distributing multiple versions of civicrm images based on different php versions (instead of just choosing one supported php version for a specific version of civicrm). I don't know the answer. I think there is more than one answer. To some extent it depends on whether you are talking about 'a single civicrm site' or civicrm-buildkit. There are other things it depends on as well ...
seancolsen
I came to this project because my local machine has PHP 7.1 and I had a need to run a client site within PHP 5.6 for troubleshooting and development. I made these changes to the code here and was able to build a CiviCRM site within a container running PHP 5.6. Yay!
Now I'm wondering what the best way would be to help other people who might be in this same situation.
Ideas:
Curious what other ideas people have. It didn't take me too long to figure out how to make these changes, but it did require some basic understanding of Docker. And I really like the idea of other people being able to use this project without having too much understanding of Docker.