source 'https://rubygems.org' gem 'rake' gem 'rspec' gem 'bundler' gem 'helix_web_services_client', :path => 'helix_web_services_client' gem 'helix_web_services', :path => 'helix_web_services' gem 'git_fusion_strings', :path => 'git_fusion_strings' gem 'unicorn' gem 'railties' group :development do gem 'p4util', '~> 0.4' gem 'asciidoctor', '~> 1.5' gem 'faker', '~> 1.4' gem 'yard', '~> 0.8' end
| # | Change | User | Description | Committed | |
|---|---|---|---|---|---|
| #7 | 16079 | Doug Scheirer | Merge from main | ||
| #6 | 16025 | Doug Scheirer | require bundler? | ||
| #5 | 16024 | Doug Scheirer | Some cloud spec forking, got the mock_raymond to spin up in cloud testing, split normal vs cloud spec output | ||
| #4 | 16014 | Doug Scheirer | Merge down from main | ||
| #3 | 15839 | Doug Scheirer | Adding unicorn to the gemfile or tests don't run | ||
| #2 | 15726 | Doug Scheirer | merge from main | ||
| #1 | 15688 | Doug Scheirer |
Populate -o //guest/perforce_software/helix-web-services/... //guest/doug_scheirer/helix-web-services/.... |
||
| //guest/perforce_software/helix-web-services/main/source/Gemfile | |||||
| #1 | 15622 | tjuricek |
Move source code to 'source/' subdirectory of branch. build/ will remain where it is. |
||
| //guest/perforce_software/helix-web-services/main/Gemfile | |||||
| #23 | 15077 | tjuricek |
Add new 'model' technique, revised branch spec operations, test Auth::Middleware. The Ruby client now does *not* strictly type anything, but extends OpenStruct with helper methods to help deal with inconsistent data formats. See the OpenModel class documentation for more details. The Auth::Middleware class is also *finally* implemented as well. This does not take into account all possible variations of server behavior (yet), but that will happen in follow-up work. |
||
| #22 | 15032 | tjuricek |
Starting config and doc revisions. System is now broken while revisions underway. Configuration of the p4d connection is now done via a single HWSSettings middleware object injected into the Rack env. The HWSP4Cleanup middleware now cleans up any p4 injected into the Rack env. The Auth::App class now mostly just contains one method to generate a p4 ticket. /auth/v1/login. Added yard documentation for the main project. Yard docs have been reconfigured to dump into build/ directories. This should probably be done with each release. Hm... The top level rake file contains a task, 'all:doc', to update our documentation. This should probably be run for each checkin. Hm... Specs are now using Rack::Test on top of a 'live' p4d. I'd suggest you still use the p4util mechanism, which now dumps to a /tmp folder, so we can safely add P4IGNORE rules back into your local .p4config file. Old 'perforce' application now called 'helix_versioning_engine'. Removing cache data. Helix Sync may be slow. It may also get axed. We'll see. |
||
| #21 | 14151 | tjuricek |
Add depot tree control and selection to the create projects page. Styling and error checking is kept to a minimum for the time being. Our goal is just internal workflow and feedback. |
||
| #20 | 13975 | tjuricek |
Reset subproject references in the top level Gemfile. This allows a single RubyMine session to drive most of the development of the different projects (well, except for the Qt libraries). |
||
| #19 | 13972 | tjuricek |
Removing old microservice implementations. The system is now mostly a monolith. Eventually there will be a websocket service. |
||
| #18 | 13768 | tjuricek |
Fixing the version of bundler to 1.8.9. The recent changes to 1.9.x don't seem to work smoothly with RVM - 'rake install' (a task defined by bundler) seems to shell out to the 'gem' command, which doesn't appear to be configured quite right when launched via an RVM wrapper script. |
||
| #17 | 13707 | tjuricek |
Infrastructure for including a "project management" React application. This attempts to create a fairly simple installer that creates a 'static' folder based on ui/static that gets hosted by the nginx front end. Right now, it's the only app, so the default page is this application. It was called "pws2" during a prototyping phase. Another prototype, "pws" and the related "project" module, is removed since that was a Sinatra-based approach that will be much more difficult to integrate into anything else. I'm running into a couple of issues with notifications setup, it's still not 100%, so I'm disabling this for now from the default 'god' configuration. (The service isn't 100% functional yet, anyway.) |
||
| #16 | 13677 | tjuricek | Fixed issues with Sequel saving and displaying webhooks in notification_services. | ||
| #15 | 13635 | tjuricek |
Exploring modular web applications with Sinatra. If the app has fairly unique content per page, Sinatra works really well actually. (Mostly because it's a thin layer over Rack.) Sharing anything though, basically means implementing a module or base class and implementing it everywhere. An added benefit is that these applications could be used in Rails apps as well. I'd probably think hard about this, because Rails tends to be a resource hog. Here's an example config.ru I used for running against the dev system: require 'pms' app = Pms::App.new Pms::Login.settings.p4_web_api_url = http://172.16.100.20/p4_web_api/v1 ProjectApp.settings.phoenix_services_url = http://172.16.100.20/p4_phoenix_services/v1 app.settings.static = :true app.settings.public_folder = File.absolute_path('../../ui/pms', __FILE__) puts "public_folder is #{app.settings.public_folder}" run app |
||
| #14 | 13525 | tjuricek |
Setup God to manage both the p4 web api and p4 project services processes. Apparently, there can only be one true god per machine. |
||
| #13 | 13520 | tjuricek |
Created a 'cluster' build procedure that creates an installer on build, and executes the install on a test instance. The main change is to package all gem dependencies via 'vendor/cache' (using the 'bundle package' command). Right now, there appears to be an issue with test data initialization, which may need a revised approach. |
||
| #12 | 13500 | tjuricek |
Reorganizing Vagrant definitions. Each platform should allow developers to launch environments for development, builds, or 'production', so the entire CD process can be evaluated by anyone wiht access to the source tree. This may eventually bring up a transient vSphere machine up and down, which may be necessary for sandboxing Omnibus related builds. |
||
| #11 | 13499 | tjuricek |
Simple p4_web_api omnibus installer. Successfully built using a test-kitchen VM for debian ubuntu 14.04. |
||
| #10 | 13481 | tjuricek |
Tests for the p4 web api and p4 project services now pass against a development setup both in and out of the docker cluster. Note that configuration *has not* been finalized, so conventions to dealing with development vs production need to be organized a bit. |
||
| #9 | 13480 | tjuricek |
Creating several Rake tasks for our "hsm" configuration that are based on a Ruby API config file. The config file points to machines and services in the system which then takes care of setting up the docker-machine environment and docker-compose configuration. |
||
| #8 | 13470 | tjuricek |
Phoenix notification services, client API, including new phoenix_updater This is an interim commit containing a first pass implementation of the phoenix_updater. Notably missing parts: - The Qt API doesn't yet actually interact with the phoenix_updater - The phoenix_services web service doesn't filter out notifications I *may* end up creating another web application *just* to filter out notifications, since this may end up taking up a lot of background workers. |
||
| #7 | 13467 | tjuricek | Add a basic notification_services endpoint that can setup a trigger entry and accept basic POST requests. | ||
| #6 | 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. |
||
| #5 | 13420 | tjuricek |
Setup the main directory to launch specs in subprojects and a unicorn-based daemon via rake. See rake -T for details, but this should allow for CI builds to collect output. |
||
| #4 | 13418 | tjuricek | Added p4_project_services to development config.ru, and reconfigured p4 web api client tests to use the new paths. | ||
| #3 | 13417 | tjuricek |
Added a 'rake work/config.ru' task, that creates a local rack configuration. This now includes the project services, which is not yet mounted. The p4 web api tests still pass though. |
||
| #2 | 13416 | tjuricek |
Set up the p4_web_api related projects to be loaded by the parent Gemfile to make it a little easier to launch a test p4d with different seed data. Also fixed a couple of minor issues related to the client api. You'll notice that the 'rake api_reset api_init' task sets up a p4d for the p4_web_api tests, where the 'rake proj_reset proj_init' tasks set up p4d for project services testing. An example p4_web_api.ru that can be used for launching just the p4_web_api: require 'p4_web_api' # Do *not* let your development environment variables pollute how the p4 web api runs! ENV.keys.select { |k| k =~ /^P4/ }.each { |k| ENV.delete(k) } api = P4WebAPI::App.new puts 'changing paths' api.settings.token_path = '/Users/tjuricek/dev/p4ws/work/tokens' api.settings.workspace_folder = '/Users/tjuricek/dev/p4ws/work/workspaces' api.settings.p4 = {'port' => 'localhost:1666', 'charset' => 'auto'} run api |
||
| #1 | 13415 | tjuricek | Add some basic utility methods to the top level. | ||