require 'sequel' Sequel.migration do up do create_table(:projects) do column :id, String, :primary_key => true, :null => false column :name, String, :null => false column :version, Integer, :default => -1 column :description, String column :owner, String column :group, String end create_table(:branches) do primary_key :id column :sid, String, :index => true column :name, String column :stream, String foreign_key :project_id, :projects, :type => String end create_table(:views) do primary_key :id column :depot_path, String, :null => false column :view_path, String, :null => false foreign_key :branch_id, :branches end create_table(:extensions) do primary_key :id foreign_key :project_id, :projects, :type => String column :content_type, String column :json, String end end down do drop_table(:extensions) drop_table(:views) drop_table(:branches) drop_table(:projects) end end
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#8 | 13972 | tjuricek |
Removing old microservice implementations. The system is now mostly a monolith. Eventually there will be a websocket service. |
||
#7 | 13789 | tjuricek |
Basic create/read methods for hooks on project services. Not connected to the main project handler yet. |
||
#6 | 13474 | tjuricek | Corrected regressions that broke the API and Project services specs. | ||
#5 | 13473 | tjuricek |
Change the name of our ':pg' rake tasks to just ':db' for some consistency. Fixed a few initial schemas to normalize on using integers for primary keys. I may need to come up with some constraints for project IDs, we'll see. |
||
#4 | 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. |
||
#3 | 13469 | tjuricek |
Initial implementation of change-commit notification services. Set up a new database just for storing webhook configuration for the notification services. It uses the stable version of Resque, which needs to be evaluated in more detail. This should be easier for an admin to monitor than something like Sidekiq, but performance evaluation needs to happen before production release. No automated tests yet, that will rely upon a Phoenix notification mechanism existing first. |
||
#2 | 13463 | tjuricek | Replace crappy indexing mechanism with Postgres queries. | ||
#1 | 13462 | tjuricek |
Created a preliminary caching schema and basic database models for the p4 project services. This may break some tests momentarily until I implement caching. |