# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#5 | 13972 | tjuricek |
Removing old microservice implementations. The system is now mostly a monolith. Eventually there will be a websocket service. |
||
#4 | 13530 | 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). |
||
#3 | 13472 | tjuricek |
Implementation of the phoenix services side of notification handling. This is just implementation and work-in-progress. Phoenix projects will now have paths cached in the phoenix services process, which we'll use to "guess" what file changes affect which Phoenix project. We basically see a changed path, then see that it might be relevant to one of the Phoenix project stream views, and then issue a "p4 changes -m1 //stream..." to see what the last change number is. If the change number goes up, we trigger an update. Note that how this all gets configured is with an account from notification services to phoenix services, which ideally is some kind of system account that sees all relevant files. Otherwise, you'll likely get changes filtered by protections, and thus, updates may not get sent out. |
||
#2 | 13455 | tjuricek | Basic Phoenix project metadata (the project name) can now be created and read back. | ||
#1 | 13421 | tjuricek |
Skeleton of the p4 phoenix services It's very likely that real 'business logic' will need to happen, but a lot of that is TBD. This is mostly to get the infrastructure in place before we start adding details, like, 'every new project lives under //phoenix/[project]/...', yada yada yada. |