| # | Change | User | Description | Committed | |
|---|---|---|---|---|---|
| #2 | 15791 | tjuricek | Removing very old p4ws branch | ||
| #1 | 13266 | tjuricek |
Reorganized depot to avoid stream/main in path. This may be re-imported. |
||
| //guest/tjuricek/p4ws/stream/main/salt/srv/perforce/web-services/notification_services/config.ru | |||||
| #1 | 13245 | tjuricek |
Add notification_services to deployment, and reconfigure build step to exec bash. The execution bit doesn't seem to stay set on config/bash.sh The notification_services service doesn't have advanced tests just yet. |
||
| //guest/tjuricek/p4ws/stream/main/salt/srv/perforce/web-services/p4_phoenix_services/config.ru | |||||
| #1 | 13240 | tjuricek |
Add p4_phoenix_services package and Salt configuration for deployment. This uncovered a couple of issues from the C++ API during it's conversion to C++03. So, in a nutshell, most operations, except for notifications, appear to be working (well, using Vagrant machines). |
||
| //guest/tjuricek/p4ws/stream/main/p4_phoenix_services/p4_phoenix_services/config.ru | |||||
| #4 | 13198 | tjuricek |
Added hsm:startworld and hsm:stopworld tasks to do global starts and stops. This is not without apparent issues. It appears bundler or ruby is pausing before the nginx launch task happens. I'm not sure if there's some kind of resource issue first. P4WEBAPI-49 |
||
| #3 | 13197 | tjuricek |
Pushing host, port, and URL configuration into docker-compose.yml consistently. All other configuration will be figured out by a separate system later. P4WEBAPI-51 |
||
| #2 | 13192 | tjuricek |
Fix issues with running the Phoenix test suite against basic CRUD operations. Does *not* test the notifications mechanism, but we have preliminary phoenix project caching on create, and does generate a simple stream for each phoenix project. |
||
| #1 | 13188 | tjuricek |
Added Docker configuration for notification services, and phoenix services, also, opened up most ports to the host by default. The current configuration is now working first for a setup of "development mode" environments, anticipating that each service will use the private internal network for most services. That way, you can selectively run things, say, in your OS X environment, and other things in the docker cluster. It can make your debugging a little easier. When more automation is available, we'll find a way to describe how to handle this in different ways. |
||