droath / project-x Goto Github PK

When the project-x drupal:local-setup is executed and ports are in use by other processes, the port check displays a prompt on which to continue. If no is selected the remaining of the setup steps are still executed.

Allow google lighthouse reports to be exported for the given project or external URL.

We need to support composer packages that set the type directive with project-x to be included for engine, and project type discovery. This type of architecture will allow developers to enhance the architecture without having to hack the project-x framework.

When exporting Drupal configurations it's tied to a UUID based on the environment that created those configurations. If you're setting up a new Drupal instance, with project-x drupal:local-setup any configurations that are defined wont be imported due to a mismatch UUID. This creates problems!

It would be ideal for project-x to keep track of the Drupal build information like the UUID in the project-x.yml. Then when new developers are onboarded they're able to run one command to setup their environment and import any configurations that are defined in the project.

There is a need to pass/fail a CI build if the google lighthouse performance drops. This could be useful for other metrics as well, accessibility, progressive web app, etc.

It would be better if the browser would open at the end of the setup task.

docker exec [CONTAINER] /var/www/html/vendor/bin/drush

This is hard to remember, so it would be nice to streamline this within the project-x command.

I just tried setting up a new project-x based project by following the instructions in istop-ng. It looks like xdebug support may have been dropped at some point between project-x 0.1.8 and 0.2.0. phpinfo() confirms that it was not installed, although many of the xdebug related environment variables are still being set.

I know this is working in 0.1.8, can you reproduce this issue? If you can't then I can tear down my project and run through set up tasks again to double check.

Motivation:

Need a build process to take place that would package up Drupal or any project type that project-x is aware of and deploy to a build repo hosted on GitHub.

It doesn't make sense for the .env to only be created when docker is setup for the first time. This needs to happen more often so when new developers get on boarded they don't have to rerun the engine install process to just generate the .env file.

We need to use >=2.8 < 3.0 for all symfony packages. This is due to Drupal 8 only being compatible with Symfony 2.8 packages at the moment. We'll create a project-x version based on the Symfony major version moving forward.

Currently project-x writes the host IP address to docker-compose-dev.yml on project setup. This is not ideal because we commit docker-compose-dev.yml to version control when working on a project and IP addresses can't be relied upon like that.

Establish the host IP address as an environment variable on engine:up so that it works even after your IP address has changed.

We had a project that ran into a problem because the theme had a required file named console that was ignored by the line "console" in the base .gitignore.

I see a number of other lines that are overly specific or redundant. Some examples:

• reports would ignore any file or directory anywhere named "reports". Doesn't seem that outlandish.
• tmp and tmp/** are redundant. The first also isn't specific enough.

Where did this .gitignore file come from? It looks like it was added all at once in 16e9fff. Seems like we should open an issue against the original source as well.

I think that most commands should bail out when they encounter an error. For example:

$ vendor/bin/project-x engine:up

➜  Project engine is preparing for takeoff. 🚀
+--------------------+-------------------+
| Port               | Status            |
+--------------------+-------------------+
| 80                 | ✅                 |
| 3306               | ✅                 |
+--------------------+-------------------+
| There is 0 warning(s) on 127.0.0.1!    |
+--------------------+-------------------+
 [Droath\RoboDockerSync\Task\DockerSync\Start] Running Docker-Sync: /usr/local/bin/docker-sync start 
 [Droath\RoboDockerSync\Task\DockerSync\Start] Running /usr/local/bin/docker-sync start 
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
       error  No docker daemon seems to be running. Did you start your docker-for-mac / docker-machine?
 [Droath\RoboDockerSync\Task\DockerSync\Start]    Time 0.887s
 [Droath\RoboDockerSync\Task\DockerSync\Start]  Exit code 1  Time 0.887s
 [File\Write] Writing to /Users/bfisher/Sites/mysite/.env.
 [File\Write] Writing to /Users/bfisher/Sites/mysite/.env.
 [Droath\RoboDockerCompose\Task\Up] Running Docker-Compose: /usr/local/bin/docker-compose  --file docker-compose.yml --file /Users/bfisher/Sites/mysite/docker-compose-dev.yml up  -d --remove-orphans 
 [Droath\RoboDockerCompose\Task\Up] Running /usr/local/bin/docker-compose  --file docker-compose.yml --file /Users/bfisher/Sites/mysite/docker-compose-dev.yml up  -d --remove-orphans 
ERROR: Couldn't connect to Docker daemon. You might need to start Docker for Mac.
 [Droath\RoboDockerCompose\Task\Up]    Time 1.035s
 [Droath\RoboDockerCompose\Task\Up]  Exit code 1  Time 1.035s
 [Filesystem\FilesystemStack] _chmod ["/Users/bfisher/Sites/mysite/docroot/sites/default/files",509,0,true]
Password:
➜  Added local.mysite.com to hosts file.
/usr/bin/open
 [Development\OpenBrowser] Opened http://local.mysite.com

Note the line

ERROR: Couldn't connect to Docker daemon. You might need to start Docker for Mac.

That is a helpful error message, and I think the command should stop there and let me start Docker (better yet, start the application after getting confirmation) instead of going on to the next step.

Provide github commands that interact with GitHub issues, etc so when working on a project you don't have to leave the cli.

Add server config options to init command. Do you want solr, memcache etc

In the output below, despite responding "no" to the question "Do you want to continue?", project-x continues to modify the hosts file and launch a browser window.

$ ./vendor/bin/project-x engine:up

➜  Project engine is preparing for takeoff. 🚀

 !                                                                                                                      
 ! [CAUTION] Another process on your system is using the same port(s).                                                  
 !           Please review the report below for more details.                                                           
 !                                                                                                                      

+--------------------+-------------------+
| Port               | Status            |
+--------------------+-------------------+
| 80                 | ❌                 |
| 3306               | ✅                 |
+--------------------+-------------------+
| There is 1 warning(s) on 127.0.0.1!    |
+--------------------+-------------------+
☝️  Do you want to continue? (y/n) [no] n
 [Filesystem\FilesystemStack] _chmod ["/Users/Remy/Sites/synchronoss/docroot/sites/default/files",509,0,true]
 1/1 [============================] 100%
➜  Added local.synchronoss.com to hosts file.
/usr/bin/open
 [Development\OpenBrowser] Opened http://local.synchronoss.com

The issue appears to be a missing a check for whether engineInstance()->up() has succeeded here

Follow on from #23

We decided to go in a slightly new direction, so starting a new branch in order to make history more readable.

Docker sync has been updated, some utility commands have been deprecated so functionality has been moved into different tools. No longer are we going to use docker-sync-daemon as it's going to be removed in 0.5.0+.

As I might have some modules that only need to be installed on the local environment. In production or staging they can be uninstalled.

`$ ./vendor/bin/project-x project:init

PHP Strict Standards: Robo\Tasks and Robo\Common\IO define the same property ($io) in the composition of Droath\ProjectX\Task\GitHubTasks.`

Drush is heavily used in the Drupal project type, and the remote environment details will allow us to generate the drush alias files.

We'll need to be able to set the GitHub user and token env variables for CI integration support.