Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

COPY settings.php /var/www #41

Open
dakkusingh opened this issue Mar 21, 2018 · 3 comments
Open

COPY settings.php /var/www #41

dakkusingh opened this issue Mar 21, 2018 · 3 comments

Comments

@dakkusingh
Copy link
Contributor

dakkusingh commented Mar 21, 2018

In Dockerfile: https://github.com/deviantintegral/drupal_tests/blob/master/Dockerfile#L62
We move the settings to outside the HTML folder, is this intentional?

I found some code in test-js.sh
https://github.com/deviantintegral/drupal_tests/blob/master/hooks/test-js.sh#L30

its doing:

# Restore and update a previously installed Drupal site.
mv ../settings.php sites/default/

I havent looked too deeply but why not move the settings.php to the correct place to begin with:

COPY settings.php /var/www/sites/default/

and remove this step in test-js.sh
https://github.com/deviantintegral/drupal_tests/blob/master/hooks/test-js.sh#L30

@deviantintegral
Copy link
Owner

As we use a separate mariadb container, a fresh test won't have a database installed. In other words, if we put settings.php in the proper place, it won't be functional because the database still has to be imported. My thinking was that by keeping it out it was more obvious that you have to do something (a drush site-install or database import) if you want a test site.

What do you think? Is there a better way to make that clear?

@dakkusingh
Copy link
Contributor Author

@deviantintegral Thank you for taking the time & replying through some of my questions, much appreciate you sharing the thought process behind some of the decisions.

I think what we are saying here is 2 things really:

  1. database setup and settings.php etc should be neatly self contained. therefore, if you need a DB, you have to instigate a "build" step.
  2. I think its worth breaking out the test steps and build steps into their own, where test is dependent on build.

I think it might be worth doing this in Robo..

example:

    protected function buildEnvironment()
    {
        $force = true;
        $tasks = [];
        $tasks[] = $this->taskFilesystemStack()
            ->copy('.travis/docker-compose.yml', 'docker-compose.yml', $force)
            ->copy('.travis/traefik.yml', 'traefik.yml', $force)
            ->copy('.travis/.env', '.env', $force)
            ->copy('.travis/config/settings.local.php',
                'web/sites/default/settings.local.php', $force)
            ->copy('.travis/config/behat.yml', 'tests/behat.yml', $force);
        $tasks[] = $this->taskExec('docker-compose pull --parallel');
        $tasks[] = $this->taskExec('docker-compose up -d');
        return $tasks;
    }

@dakkusingh
Copy link
Contributor Author

In general, I am quite partial to wrapping up all my tasks in Robo rather than bash.

Here is what I am currently doing for coding standards..
screen shot 2018-03-23 at 5 46 23 pm

happy to work with you in roboising the scripts if thats a direction you see pursuing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants